FEDERAL INFORMATION PROCESSING
STANDARDS PUBLICATIONS
FIPS PUB 46-2, 1993 DECEMBER 30 FIPS PUB 46-2, 1993 DECEMBER 30
Federal Information Processing Standards Publication 46-2
1993 December 30
Announcing the DATA ENCRYPTION STANDARD (DES)
Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National
Institute of Standards and Technology after approval by the Secretary of Commerce pursuant to
Section 111(d) of the Federal Property and Administrative Services Act of 1949 as amended by the
Computer Security Act of 1987, Public Law 100-235. 1. Name of Standard. Data Encryption Standard
(DES). 2. Category of Standard. Computer Security. 3. Explanation. The Data Encryption Standard
(DES) specifies a FIPS approved cryptographic algorithm as required by FIPS 140-1. This publication
provides a complete description of a mathematical algorithm for encrypting (enciphering) and
decrypting (deciphering) binary coded information. Encrypting data converts it to an unintelligible
form called cipher. Decrypting cipher converts the data back to its original form called plaintext. The
algorithm described in this standard specifies both enciphering and deciphering operations which are
based on a binary number called a key. A key consists of 64 binary digits ("O"s or "1"s) of which 56
bits are randomly generated and used directly by the algorithm. The other 8 bits, which are not used by
the algorithm, are used for error detection. The 8 error detecting bits are set to make the parity of each
8-bit byte of the key odd, i.e., there is an odd number of "1"s in each 8-bit byte. Authorized users of
encrypted computer data must have the key that was used to encipher the data in order to decrypt it.
The encryption algorithm specified in this standard is commonly known among those using the
standard. The unique key chosen for use in a particular application makes the results of encrypting data
using the algorithm unique. Selection of a different key causes the cipher that is produced for any
given set of inputs to be different. The cryptographic security of the data depends on the security
provided for the key used to encipher and decipher the data. Data can be recovered from cipher only by
using exactly the same key used to encipher it. Unauthorized recipients of the cipher who know the
algorithm but do not have the correct key cannot derive the original data algorithmically. However,
anyone who does have the key and the algorithm can easily decipher the cipher and obtain the original
data. A standard algorithm based on a secure key thus provides a basis for exchanging encrypted
computer data by issuing the key used to encipher it to those authorized to have the data. Data that is
considered sensitive by the responsible authority, data that has a high value, or data that represents a
high value should be cryptographically protected if it is vulnerable to unauthorized disclosure or
undetected modification during transmission or while in storage. A risk analysis should be performed
under the direction of a responsible authority to determine potential threats. The costs of providing
cryptographic protection using this standard as well as alternative methods of providing this protection
and their respective costs should be projected. A responsible authority then should make a decision,
based on these analyses, whether or not to use cryptographic protection and this standard. 4.
Approving Authority. Secretary of Commerce. 5. Maintenance Agency. U.S. Department of
Commerce, National Institute of Standards and Technology, Computer Systems Laboratory. 6.
Applicability. This standard may be used by Federal departments and agencies when the following
conditions apply: 1. An authorized official or manager responsible for data security or the security of
any computer system decides that cryptographic protection is required; and 2. The data is not classified
according to the National Security Act of 1947, as amended, or the Atomic Energy Act of 1954, as
amended. Federal agencies or departments which use cryptographic devices for protecting data
classified according to either of these acts can use those devices for protecting unclassified data in lieu
of the standard. Other FIPS approved cryptographic algorithms may be used in addition to, or in lieu
of, this standard when implemented in accordance with FIPS 140-1. In addition, this standard may be
adopted and used by non-Federal Government organizations. Such use is encouraged when it provides
the desired security for commercial and private organizations. 7. Applications. Data encryption
(cryptography) is utilized in various applications and environments. The specific utilization of
encryption and the implementation of the DES will be based on many factors particular to the
computer system and its associated components. In general, cryptography is used to protect data while
it is being communicated between two points or while it is stored in a medium vulnerable to physical
theft. Communication security provides protection to data by enciphering it at the transmitting point
and deciphering it at the receiving point. File security provides protection to data by enciphering it
when it is recorded on a storage medium and deciphering it when it is read back from the storage
medium. In the first case, the key must be available at the transmitter and receiver simultaneously
during communication. In the second case, the key must be maintained and accessible for the duration
of the storage period. FIPS 171 provides approved methods for managing the keys used by the
algorithm specified in this standard. 8. Implementations. Cryptographic modules which implement this
standard shall conform to the requirements of FIPS 140-1. The algorithm specified in this standard may
be implemented in software, firmware, hardware, or any combination thereof. The specific
implementation may depend on several factors such as the application, the environment, the
technology used, etc. Implementations which may comply with this standard include electronic devices
(e.g., VLSI chip packages), micro-processors using Read Only Memory (ROM), Programmable Read
Only Memory (PROM), or Electronically Erasable Read Only Memory (EEROM), and mainframe
computers using Random Access Memory (RAM). When the algorithm is implemented in software or
firmware, the processor on which the algorithm runs must be specified as part of the validation process.
Implementations of the algorithm which are tested and validated by NIST will be considered as
complying with the standard. Note that FIPS 140-1 places additional requirements on cryptographic
modules for Government use. Information about devices that have been validated and procedures for
testing and validating equipment for conformance with this standard and FIPS 140-1 are available from
the National Institute of Standards and Technology, Computer Systems Laboratory, Gaithersburg, MD
20899. 9. Export Control. Cryptographic devices and technical data regarding them are subject to
Federal Government export controls as specified in Title 22, Code of Federal Regulations, Parts 120
through 128. Some exports of cryptographic modules implementing this standard and technical data
regarding them must comply with these Federal regulations and be licensed by the U.S. Department of
State. Other exports of cryptographic modules implementing this standard and technical data regarding
them fall under the licensing authority of the Bureau of Export Administration of the U.S. Department
of Commerce. The Department of Commerce is responsible for licensing cryptographic devices used
for authentication, access control, proprietary software, automatic teller machines (ATMs), and certain
devices used in other equipment and software. For advice concerning which agency has licensing
authority for a particular cryptographic device, please contact the respective agencies. 10. Patents.
Cryptographic devices implementing this standard may be covered by U.S. and foreign patents issued
to the International Business Machines Corporation. However, IBM has granted nonexclusive, royaltyfree licenses under the patents to make, use and sell apparatus which complies with the standard. The
terms, conditions and scope of the licenses are set out in notices published in the May 13, 1975 and
August 31, 1976 issues of the Official Gazette of the United States Patent and Trademark Office (934
O.G. 452 and 949 O.G. 1717). 11. Alternative Modes of Using the DES. FIPS PUB 81, DES Modes of
Operation, describes four different modes for using the algorithm described in this standard. These four
modes are called the Electronic Codebook (ECB) mode, the Cipher Block Chaining (CBC) mode, the
Cipher Feedback (CFB) mode, and the Output Feedback (OFB) mode. ECB is a direct application of
the DES algorithm to encrypt and decrypt data; CBC is an enhanced mode of ECB which chains
together blocks of cipher text; CFB uses previously generated cipher text as input to the DES to
generate pseudorandom outputs which are combined with the plaintext to produce cipher, thereby
chaining together the resulting cipher; OFB is identical to CFB except that the previous output of the
DES is used as input in OFB while the previous cipher is used as input in CFB. OFB does not chain
the cipher. 12. Implementation of this standard. This standard became effective July 1977. It was
reaffirmed in 1983, 1988, and 1993. It applies to all Federal agencies, contractors of Federal agencies,
or other organizations that process information (using a computer or telecommunications system) on
behalf of the Federal Government to accomplish a Federal function. Each Federal agency or
department may issue internal directives for the use of this standard by their operating units based on
their data security requirement determinations. FIPS 46-2 which revises the implementation of the Data
Encryption Algorithm to include software, firmware, hardware, or any combination thereof, is effective
June 30, 1994. This revised standard may be used in the interim period before the effective date. NIST
provides technical assistance to Federal agencies in implementing data encryption through the issuance
of guidelines and through individual reimbursable projects. The National Security Agency assists
Federal departments and agencies in communications security for classified applications and in
determining specific security requirements. Instructions and regulations for procuring data processing
equipment utilizing this standard are included in the Federal Information Resources Management
Regulation (FIRMR) Subpart 201-8.111-1. 13. Specifications. Federal Information Processing
Standard (FIPS) 46-2, Data Encryption Standard (DES) (affixed). 14. Cross Index. a. Federal
Information Resources Management Regulations (FIRMR) subpart 201.20.303, Standards, and subpart
201.39.1002, Federal Standards. b. FIPS PUB 31, Guidelines to ADP Physical Security and Risk
Management. c. FIPS PUB 41, Computer Security Guidelines for Implementing the Privacy Act of
1974. d. FIPS PUB 65, Guideline for Automatic Data Processing Risk Analysis. e. FIPS PUB 73,
Guidelines for Security of Computer Applications. f. FIPS PUB 74, Guidelines for Implementing and
Using the NBS Data Encryption Standard. g. FIPS PUB 81, DES Modes of Operation. h. FIPS PUB
87, Guidelines for ADP Contingency Planning. i. FIPS PUB 112, Password Usage. j. FIPS PUB 113,
Computer Data Authentication. k. FIPS PUB 140-1, Security Requirements for Cryptographic
Modules. l. FIPS PUB 171, Key Management Using ANSI X9.17. m. Other FIPS and Federal
Standards are applicable to the implementation and use of this standard. In particular, the Code for
Information Interchange, Its Representations, Subsets, and Extensions (FIPS PUB 1-2) and other
related data storage media or data communications standards should be used in conjunction with this
standard. A list of currently approved FIPS may be obtained from the National Institute of Standards
and Technology, Computer Systems Laboratory, Gaithersburg, MD 20899. 15. Qualifications. The
cryptographic algorithm specified in this standard transforms a 64-bit binary value into a unique 64-bit
binary value based on a 56-bit variable. If the complete 64-bit input is used (i.e., none of the input bits
should be predetermined from block to block) and if the 56-bit variable is randomly chosen, no
technique other than trying all possible keys using known input and output for the DES will guarantee
finding the chosen key. As there are over 70,000,000,000,000,000 (seventy quadrillion) possible keys
of 56 bits, the feasibility of deriving a particular key in this way is extremely unlikely in typical threat
environments. Moreover, if the key is changed frequently, the risk of this event is greatly diminished.
However, users should be aware that it is theoretically possible to derive the key in fewer trials (with a
correspondingly lower probability of success depending on the number of keys tried) and should be
cautioned to change the key as often as practical. Users must change the key and provide it a high level
of protection in order to minimize the potential risks of its unauthorized computation or acquisition.
The feasibility of computing the correct key may change with advances in technology. A more
complete description of the strength of this algorithm against various threats is contained in FIPS PUB
74, Guidelines for Implementing and Using the NBS Data Encryption Standard. When correctly
implemented and properly used, this standard will provide a high level of cryptographic protection to
computer data. NIST, supported by the technical assistance of Government agencies responsible for
communication security, has determined that the algorithm specified in this standard will provide a
high level of protection for a time period beyond the normal life cycle of its associated equipment. The
protection provided by this algorithm against potential new threats will be reviewed within 5 years to
assess its adequacy (See Special Information Section). In addition, both the standard and possible
threats reducing the security provided through the use of this standard will undergo continual review
by NIST and other cognizant Federal organizations. The new technology available at that time will be
evaluated to determine its impact on the standard. In addition, the awareness of any breakthrough in
technology or any mathematical weakness of the algorithm will cause NIST to reevaluate this standard
and provide necessary revisions. At the next review (1998), the algorithm specified in this standard
will be over twenty years old. NIST will consider alternatives which offer a higher level of security.
One of these alternatives may be proposed as a replacement standard at the 1998 review. 16.
Comments. Comments and suggestions regarding this standard and its use are welcomed and should be
addressed to the National Institute of Standards and Technology, Attn: Director, Computer Systems
Laboratory, Gaithersburg, MD 20899. 17. Waiver Procedure. Under certain exceptional circumstances,
the heads of Federal departments and agencies may approve waivers to Federal Information Processing
Standards (FIPS). The head of such agency may redelegate such authority only to a senior official
designated pursuant to section 3506(b) of Title 44, United States Code. Waiver shall be granted only
when: a. Compliance with a standard would adversely affect the accomplishment of the mission of an
operator of a Federal computer system; or b. Compliance with a standard would cause a major adverse
financial impact on the operator which is not offset by Government-wide savings. Agency heads may
act upon a written waiver request containing the information detailed above. Agency heads may also
act without a written waiver request when they determine that conditions for meeting the standard
cannot be met. Agency heads may approve waivers only by a written decision which explains the basis
on which the agency head made the required finding(s). A copy of each decision, with procurement
sensitive or classified portions clearly identified, shall be sent to: National Institute of Standards and
Technology; ATTN: FIPS Waiver Decisions, Technology Building, Room B-154, Gaithersburg, MD
20899. In addition, notice of each waiver granted and each delegation of authority to approve waivers
shall be sent promptly to the Committee on Government Operations of the House of Representatives
and the Committee on Government Affairs of the Senate and shall be published promptly in the
Federal Register. When the determination on a waiver applies to the procurement of equipment and/or
services, a notice of the waiver determination must be published in the Commerce Business Daily as a
part of the notice of solicitation for offers of an acquisition or, if the waiver determination is made after
that notice is published, by amendment to such notice. A copy of the waiver, any supporting
documents, the document approving the waiver and any accompanying documents, with such deletions
as the agency is authorized and decides to make under 5 United States Code Section 552(b), shall be
part of the procurement documentation and retained by the agency. 18. Special Information. In
accordance with the Qualifications Section of this standard, reviews of this standard have been
conducted every 5 years since its adoption in 1977. The standard was reaffirmed during each of those
reviews. This revision to the text of the standard contains changes which allow software
implementations of the algorithm and which permit the use of other FIPS approved cryptographic
algorithms. 19. Where to Obtain Copies of the Standard. Copies of this publication are for sale by the
National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. When
ordering, refer to Federal Information Processing Standards Publication 46-2 (FIPS PUB 46-2), and
identify the title. When microfiche is desired, this should be specified. Prices are published by NTIS in
current catalogs and other issuances. Payment may be made by check, money order, deposit account or
charged to a credit card accepted by NTIS. FIPS PUB 146-1, 1992 July 15 FIPS PUB 146-1, 1992 July
15
Federal Information Processing Standards Publication 146-1
1992 July 15 U.S. DEPARTMENT OF COMMERCE / National Institute of Standards and Technology
Standard Security Label for the Government Open Systems
Interconnection Profile
CATEGORY: ADP OPERATIONS SUBCATEGORY: COMPUTER SECURITY U.S.
DEPARTMENT OF COMMERCE, Barbara Hackman Franklin, Secretary NATIONAL INSTITUTE
OF STANDARDS AND TECHNOLOGY, John W. Lyons, Director
Foreword
The Federal Information Processing Standards Publication Series of the National Institute of Standards
and Technology (NIST) is the official publication relating to standards and guidelines adopted and
promulgated under the provisions of Section 111(d) of the Federal Property and Administrative
Services Act of 1949 as amended by the Computer Security Act of 1987, Public Law 100-235. These
mandates have given the Secretary of Commerce and NIST important responsibilities for improving
the utilization and management of computer and related telecommunications systems in the Federal
Government. The NIST, through the Computer Systems Laboratory, provides leadership, technical
guidance, and coordination of Government efforts in the development of standards and guidelines in
these areas. Comments concerning Federal Information Processing Standards Publications are
welcomed and should be addressed to the Director, Computer Systems Laboratory, National Institute
of Standards and Technology, Gaithersburg, MD, 20899. James H. Burrows, Director Computer
Systems Laboratory
Abstract
This Standard specifies a security label for the U.S. Government Open Systems Interconnection Profile
(GOSIP). GOSIP security labels indicate to protocol entities how to handle unclassified but sensitive
data communicated between open systems. Information carried by the label described here can be used
to control access, specify protective measures, and indicate other handling restrictions required by a
communications security policy. The specification for this security label is given in Abstract Syntax
Notation 1 (ASN.1) form, an implementation independent notation. A label encoding for use at the
Network and Transport Layers is given in an Appendix. Key words: ADP security, U.S. Government
Open Systems Interconnection Profile (GOSIP) security, network security, security labels, trusted Open
Systems Interconnection (OSI) Federal Information Processing Standard Publication XXX 1992 July
15
ANNOUNCING A Standard Security Label for the Government Open
Systems Interconnection Profile
Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National
Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant to
Section 111(d) of the Federal Property and Administrative Services Act of 1949 as amended by the
Computer Security Act of 1987, Public Law 100-235. Name of Standard: Standard Security Label for
the Government Open Systems Interconnection Profile. Category of Standard: ADP Operations,
Computer Security. Explanation: This Standard gives an implementation independent specification of a
security label for the U.S. Government Open Systems Interconnection Profile (GOSIP). Security labels
indicate sensitivity and the possible damage which may occur due to accidental or intentional
disclosure, modification, or destruction of data. Labels are used to make access control decisions, to
specify protective measures, and to indicate handling restrictions required by a communications
security policy. The Standard Security Label is intended for use on U. S. Government OSI networks
that exchange unclassified but sensitive data. The label presented here defines security tags that may be
combined into tag sets to carry security-related information. Five basic security tag types allow the
representation of bit maps, attribute enumerations, attribute range selections, security level indication,
and of generic information in a free form field. A Computer Security Objects Register (CSOR),
established by NIST, will provide the semantics for labels represented using this standard. Documents
referencing this labeling standard shall either point to a CSOR and its procedures for registration of
labels, or provide all the pertinent information regarding the label(s) to be supported. Approving
Authority: Secretary of Commerce. Maintenance Agency: Computer Systems Laboratory, National
Institute of Standards and Technology. Cross Index: Federal Information Resources Management
Regulations, subpart 201-20.303, Standards, and subpart 201-39.1002, Federal Standards. "Procedures
for Registration of Computer Security Objects", NIST 1992. "U.S. Government Open Systems
Interconnection Profile" (GOSIP), FIPS PUB 146-1, April 1991. Scope: This standard specifies, in
abstract notation, a security label for GOSIP-compliant implementations. Following this
implementation independent specification, security labels may be encoded for use within various Open
Systems Interconnection (OSI) protocols. The Abstract Syntax Notation 1 (ASN.1) label description
provided here shall be used for security labels in Application Layer protocols. A normative Appendix
to this standard provides the label encoding for the Network and Transport Layers. Other encodings of
this Standard Label may be produced for use at the remaining layers if necessary. The specification
given here is limited to the syntactic aspect of the label. The semantics of security labels, as defined for
different security domains, are given by a Computer Security Objects Register. Applicability: The
specified Standard Security Label (SSL) applies to OSI communications systems handling U.S.
government unclassified but sensitive data. This security label type shall be used by OSI systems
required to label data as indicated in the security chapter of GOSIP. The SSL shall be used by OSI
protocols to control access, specify protective measures, and indicate handling restrictions required by
a network security policy as registered in a Computer Security Objects Register. Complying
implementations shall be capable of transmitting, receiving, and handling security labels based on the
high level specification in this document. Specifications: Federal Information Processing Standard
(FIPS xxx) Standard Security Label for the Government Open Systems Interconnection Profile
(affixed). Implementation Schedule: This standard becomes effective six months after publication of a
notice in the Federal Register of its approval by the Secretary of Commerce. Waiver Procedure: Under
certain exceptional circumstances, the heads of Federal departments and agencies may approve waivers
to Federal Information Processing Standards (FIPS). The head of such agency may redelegate such
authority only to a senior official designated pursuant to section 3506(b) of Title 44, United States
Code. Waiver shall be granted only when: a. Compliance with a standard would adversely affect the
accomplishment of the mission of an operator of a Federal computer system; or b. Compliance with a
standard would cause a major adverse financial impact on the operator which is not offset by
Government-wide savings. Agency heads may act upon a written waiver request containing the
information detailed above. Agency heads may also act without a written waiver request when they
determine that conditions for meeting the standard cannot be met. Agency heads may approve waivers
only by a written decision which explains the basis on which the agency head made the required
finding(s). A copy of each decision, with procurement sensitive or classified portions clearly identified,
shall be sent to: National Institute of Standards and Technology; ATTN: FIPS Waiver Decisions,
Technology Building, Room B-154, Gaithersburg, MD 20899. In addition, notice of each waiver
granted and each delegation of authority to approve waivers shall be sent promptly to the Committee
on Government Operations of the House of Representatives and the Committee on Government Affairs
of the Senate and shall be published promptly in the Federal Register. When the determination on a
waiver applies to the procurement of equipment and/or services, a notice of the waiver determination
must be published in the Commerce Business Daily as a part of the notice of solicitation for offers of
an acquisition or, if the waiver determination is made after that notice is published, by amendment to
such notice. A copy of the waiver, any supporting documents, the document approving the waiver and
any accompanying documents, with such deletions as the agency is authorized and decides to make
under 5 United States Code Section 552(b), shall be part of the procurement documentation and
retained by the agency. Special Information: References to this standard will appear in the security
chapter of the U.S Government Open Systems Interconnection Profile (GOSIP) in a planned version 3
and future versions. Modifications to the planned version 3 will maintain backwards compatibility with
the labeling options defined for the Connectionless Network Protocol (CLNP) in the first two versions.
NIST plans that security protocols added to GOSIP in the future that require security labels will only
use the Standard Security Label described in this document. Where to Obtain Copies: Copies of this
publication are for sale by the National Technical Information Service, U.S. Department of Commerce,
Springfield, VA 22161. When ordering, refer to Federal Information Processing Standards Publication
XX (FIPS PUB XX), and identify the title. When microfiche is desired, this should be specified. Prices
are published by NTIS in current catalogs and other issuances. Payment may be made by check, money
order, deposit account or charged to a credit card accepted by NTIS. Federal Information Processing
Standard Publication xxx 1992 July 15
Specifications for a Standard Security Label for the Government Open
Systems Interconnection Profile
1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. REFERENCES . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 9 3. ACRONYMS AND DEFINITIONS . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 Acronyms. .
. . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. SECURITY
LABEL SPECIFICATION . . . . . . . . . . . . . . . . . . . . . 12 5. EXPLANATION AND USAGE. . . . . . . . .
. . . . . . . . . . . . . . . . 13 5.1 Registered Fields . . . . . . . . . . . . . . . . . . . . . . . 14 5.2 Security Tag Set
Name . . . . . . . . . . . . . . . . . . . . . 14 5.3 Security Tag Set. . . . . . . . . . . . . . . . . . . . . . . . 15 5.3.1
Security Tag Type 1 . . . . . . . . . . . . . . . . . . 15 5.3.2 Security Tag Type 2 . . . . . . . . . . . . . . . . . . 16
5.3.3 Security Tag Type 3 . . . . . . . . . . . . . . . . . . 16 5.3.4 Security Tag Type 4 . . . . . . . . . . . . . . . . . .
16 5.3.5 Security Tag Type 5 . . . . . . . . . . . . . . . . . . 17 Appendix A: Standard Security Label
Encoding for the Network and Transport Layers . . . . . . . . . . . . . . . . . . . . . . . . 18 A.1 Local Acronyms
and Definitions. . . . . . . . . . . . . . . . . 18 A.2 Security Label Format . . . . . . . . . . . . . . . . . . . . . 18 A.3
Security Label Indicator. . . . . . . . . . . . . . . . . . . . 19 A.4 Length Indicator. . . . . . . . . . . . . . . . . . . . . . . .
19 A.5 Registered Field Set. . . . . . . . . . . . . . . . . . . . . . 19 A.5.1 Tag Set Name Length . . . . . . . . . . . . .
. . . . . 19 A.5.2 Tag Set Name. . . . . . . . . . . . . . . . . . . . . . 20 A.5.3 Tag Set Length. . . . . . . . . . . . . . . . .
. . . . 20 A.5.4 Security Tags . . . . . . . . . . . . . . . . . . . . . 20 A.5.4.1 Security Tag Type. . . . . . . . . . . . . . .
. . . 20 A.5.4.2 Security Tag Length. . . . . . . . . . . . . . . . . 20 A.5.4.3 Security Information . . . . . . . . . . .
. . . . . 21 A.5.4.3.1 Security Tag Type 1 . . . . . . . . . . . . . 21 A.5.4.3.2 Security Tag Type 2 . . . . . . . . . .
. . . 21 A.5.4.3.3 Security Tag Type 3 . . . . . . . . . . . . . 22 A.5.4.3.4 Security Tag Type 4 . . . . . . . . . . . .
. 23 A.5.4.3.5 Security Tag Type 5 . . . . . . . . . . . . . 23 A.6 Usage Rules . . . . . . . . . . . . . . . . . . . . . . . .
. . 23
1. INTRODUCTION
U.S. Government agencies are required to protect data essential to their operations. This requirement
covers data stored, processed, and transmitted by computer and communications systems. This
standard defines, in abstract notation, a security label type for use in the U.S. Government Open
Systems Interconnection (OSI) Profile (GOSIP, FIPS PUB 146-1) [10]. GOSIP is a mandatory set of
specifications for procurement of OSI communications systems. The security label specified here may
be used to indicate data sensitivity and possible damage due to accidental or intentional disclosure,
modification, or destruction. Labels following this specification can be used to make access control
decisions, specify protective measures, and indicate handling restrictions required by the applicable
security policy. The Abstract Syntax Notation 1 (ASN.1) [4] is used to define the Standard Security
Label (SSL). ASN.1 provides an implementation independent means of expressing complex
Application Layer protocol elements. ASN.1 specifications are typically encoded using the Basic
Encoding Rules (BER) [5], although other encodings may be used. Our security labeling approach
takes advantage of this flexibility to specify a common label type for use throughout the OSI stack.
The ASN.1 specification of the SSL can be encoded to conform to specific layer protocols. This
standard provides the encoding for security labels at OSI layers 3 and 4 in a normative appendix.
Documents calling for encodings of the SSL for use at layers other than 3 and 4, shall provide such
encoding or a reference to the document providing the encoding. The SSL provides a set of tools that
can be combined to support different security policies. Instances of this type of labels are registered in
a Computer Security Objects Register (CSOR) where the rules for their interpretation are given. The
CSOR associates a unique object identifier to each label definition provided thus enabling
implementations to identify the labels and process them accordingly. Documents referencing this FIPS
shall indicate the source and all information necessary for the use and implementation of the labels to
be supported. This includes the identity of the CSOR, identifiers, and definitions for all labeling
objects supported.
2. REFERENCES
[1] European Computer Manufacturers Association, "Security in Open Systems - Data Elements and
Service Definitions", ECMA Standard 138, December 1989. [2] International Standards Organization
(ISO), "Information processing systems - Open Systems Interconnection - Basic Model", ISO 7498,
1988. [3] International Standards Organization (ISO), "Information processing systems - Open Systems
Interconnection - Security Addendum", ISO 7498/2, 1988. [4] International Standards Organization
(ISO), "Information Technology - Open Systems Interconnection - Specification of Abstract Syntax
Notation One (ASN.1)", ISO/IEC 8824 (DIS), 1990. [5] International Standards Organization (ISO),
"Information Technology - Open Systems Interconnection - Specification of Basic Encoding Rules for
Abstract Syntax Notation One (ASN.1)", ISO/IEC 8825 (DIS), 1990. [6] Internet CIPSO Working
Group, "Commercial IP Security Option", Proposed Request for Comments (RFC), February 7, 1991.
[7] Nazario Noel, "Security Labeling in Unclassified Networks", Proceedings of the 13th National
Computer Security Conference, Volume 1, pp. 44-48, October 1990. [8] Nazario Noel, "Security
Labels for Open Systems - An Invitational Workshop", NISTIR 4362, June 1990. [9] Nazario Noel,
"Standard Security Label for GOSIP - An Invitational Workshop", NISTIR 4614, June 1991. [10]
"U.S. Government Open Systems Interconnection Profile" (GOSIP), FIPS PUB 146-1, April 1991.
3. ACRONYMS AND DEFINITIONS
3.1 Acronyms CSOR - Acronym for Computer Security Objects Register. GOSIP - Acronym for (U.S.)
Government Open Systems Interconnection Profile. GOSIP, or Federal Information Processing
Standard (FIPS) 146-1, is a procurement profile for open systems computer network products. [10] OSI
- Acronym for Open System Interconnection. PDU - Acronym for Protocol Data Unit. TSN - Acronym
for Tag Set Name. 3.2 Definitions computer security object - (CSO). A resource, tool, or mechanism
used to maintain a condition of security in a computerized environment. These objects are defined in
terms of attributes they possess, operations they perform or are performed on them, and their
relationship with other objects. Computer Security Objects Register - (CSOR). A collection of CSO
names and definitions kept by a registration authority. domain - See security domain. entity - An active
element in an open system. [2] open system - A set of one or more computers, the associated software,
peripherals, terminals, human operators, physical processes, information transfer means, etc., that
forms an autonomous whole capable of processing and/or transferring information that complies with
the requirements of OSI standards. [2] Open Systems Interconnection - This term qualifies standards
for the exchange of information among systems that are "open"to one another for this purpose by
virtue of their mutual use of applicable standards. The Basic reference model for OSI is given in [2].
protocol data unit - A unit of data specified in a protocol and consisting of protocol information and,
possibly, user data.[2] policy - See security policy protocol entity - Entity that follows a set of rules and
formats (semantic and syntactic) that determine the communication behavior of other entities. [2]
Registered Field - An instance of an entry to the Computer Security Objects Register (CSOR) as
carried in the label. Contains a Tag Set Name and a set of tags. registration authority - Organization
responsible for the maintenance of a branch of the ISO naming hierarchy. security attribute - A
security-related quality of a security object. Security attributes may be represented as hierarchical
levels, bits in a bit map, or numbers. Compartments, caveats, and release markings are examples of
security attributes. security domain - A collection of entities to which applies a single security policy
executed by a single security administrator. [1] security label - A marking bound to a resource (which
may be a data unit) that names or designates the security attributes of that resource. [3] security policy A set of criteria for the provision of security services that provide adequate protection for systems and
data transfers. [3] A set of rules that define and constrain the activities of a data processing facility in
order to maintain a condition of security. [1] security tag - Information unit containing a representation
of certain security-related information (e.g., a category bit map). security threat - Circumstance with the
potential to cause loss or harm to a computer system or the information it handles. Tag Set Name Unique object identifier associated with a set of security tags.
4. SECURITY LABEL SPECIFICATION
The Abstract Syntax Notation 1 (ASN.1) [4] definition of the Standard Security Label (SSL) is given in
Figure 4.1 below. This definition shall be encoded as appropriate to the layer where it will be used. At
the Network and Transport Layers, the encoding given in the appendix shall be used.
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDDDDDDDDD D 3 ASN.1 Definition for Standard Security Label 3 3 3 3 Standard
Security Label ::= IMPLICIT SET OF RegisteredField 3 3 3 3 RegisteredField ::= IMPLICIT
SEQUENCE { 3 3 3 tagsetname TagSetName, 3 3 3 securityTags SEQUENCE OF SecurityTag } 3 3 3
3 TagSetName ::= OBJECT IDENTIFIER 3 3 3 3 SecurityTag ::= CHOICE { 3 3 3 -- Type 1 3 3
bitMap [1] IMPLICIT BIT STRING, 3 3 3 -- Type 2 3 3 enumeratedAttributes [2] IMPLICIT SET OF
SecurityAttribute, 3 3 3 -- Type 3 3 3 rangeset [3] IMPLICIT SET OF SecurityAttributeRange, 3 3 3 -Type 4 3 3 securityLevel [4] IMPLICIT SecurityAttribute, 3 3 3 -- Type 5 3 3 freeFormField [5]
IMPLICIT ANY DEFINED BY TagSetName } 3 3 3 3 SecurityAttributeRange ::= IMPLICIT
SEQUENCE { 3 3 3 upperBound SecurityAttribute, 3 3 3 lowerbound SecurityAttribute } 3 3 3 3
SecurityAttribute ::= IMPLICIT INTEGER (0..65535) 3 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDDDDDDDDDD D Figure 4.1
5. EXPLANATION AND USAGE
According to the above abstract definition for the (SSL), a security label is defined as a collection of
Registered Fields. These Registered Fields contain security information required by an organization's
security policy. This information is used to maintain the security condition of a resource (e.g.,
communications system, data file, application process). 3DDDDDDD Standard Security Label
DDDDDD3 ZDDDDDDDDDDDDBDDDD DDDBDDDDDDDDDDDD? 3 Registered 3 3 Registered
3 3 Field 1 3 3 Field N 3 @DDDDDDDDDDDDADD DDDDDDADDDDDDDDDDDDY Figure 5.1
5.1 Registered Fields Registered Fields are an instance of a security label registered in a Computer
Security Objects Register (CSOR). A Registered Field has two parts, a security tag set name (TSN),
and a security tag set. The TSN is an unique name associated with the semantics for interpreting the
security tags carried in the field. The security tags carry the actual security information. A Registered
Field is depicted in Figure 5.2. Every SSL must carry, at least, one Registered Field. The use of
multiple Registered Fields in a single label provide for protection under multiple security policies. This
is useful for maintaining an appropriate degree of protection when information is shared across security
domain boundaries. Implementations shall be able to scan the whole label even if a Registered Field is
not recognized. Failure to recognize a Registered Field may constitute a security relevant event. The
system security policy is responsible for identifying those events whose occurrence is relevant and
indicating the action to follow. 3DDDDDDDDDDDD Registered Field DDDDDDDDDDD3
ZDDDDDDDDD?ZDDDDDDDDDDBD DDDDDBDDDDDDDDDD? 3 Tag Set 33 Security 3 3
Security 3 3 Name 33 Tag 3 3 Tag 3 @DDDDDDDDDY@DDDDDDDDDDADDDD
DADDDDDDDDDDY Figure 5.2 5.2 Security Tag Set Name Security tag set names (TSNs) uniquely
identify the labeling scheme supported by the data in the set of security tags that follow. A Computer
Security Objects Register (CSOR) maintains the semantics necessary for interpretation of label
information. The Register assigns unique TSNs based on a hierarchy of registration authorities. These
unique names are described in terms of Object Identifiers as defined for the Abstract Syntax Notation 1
(ASN.1) [4]. Documents referencing this labeling standard shall either point to a CSOR and its
procedures for registration of labels, or indicate the TSN and definition of the label(s) to be supported.
5.3 Security Tag Set The set of security tags in each Registered Field carry the security information.
Five tag types are defined in this standard. These tag types are, (1) Bit Map, (2) Enumerated, (3)
Range, (4) Security Level, and (5) Free Form. Any combination of tag types may be used to represent
the security information required by the local security policy for protection of the data being
exchanged. This standard relies on the services of a Computer Security Objects Register to maintain
the tag-specific information necessary for the correct implementation of labels. Upon registration, the
value and significance of the following items shall be provided: number of tags, number of tags of each
type, length of the set, length of each tag, ordering of tags, security relevant conditions, The above list
may be augmented by the Registration Authority for the CSOR. 5.3.1 Security Tag Type 1 Tag type 1
is the Bit Map Tag Type. Tags of this type are used to convey security parameters, such as
compartments and protection categories, that may be selected from a set by setting a one-bit flag to a
predefined value (logic 0 or 1). The use of either 0s or 1s to mark the set condition of the individual
bits allows the implementation of permissive (e.g., release markings) and restrictive (e.g., categories)
markings using the same mechanism to test both conditions. 5.3.2 Security Tag Type 2 Tag type 2 is
the Enumerated Tag Type. Tags of this type are used when only a few security attributes out of a large
set need to be singled out when labeling a given protocol data unit (PDU). This is done by assigning a
fixed-size non-negative binary number to each security attribute and enumerating those attributes that
apply (set inclusion), or do not apply (set exclusion). This enumeration shall start with the lowest
numbered attribute following an ascending order. The entry registered in the CSOR will indicate
whether attributes enumerated in a type 2 tag will be interpreted as included or excluded from the
applicable set. 5.3.3 Security Tag Type 3 Tag Type 3 is the Range Tag Type. Tags of this type are used
when all the security attributes between certain lower and upper bound need to be singled out when
labeling a PDU. This is done by indicating the higher-numbered and lower-numbered attributes as
bounds for the range. The entry registered in the CSOR will indicate whether attributes in a range will
be interpreted as included or excluded from the applicable set. A single tag may indicate multiple
security attribute ranges. These ranges shall be listed in descending numerical order and shall not
overlap. Each upper or lower bound attribute is indicated by a fixed size number. 5.3.4 Security Tag
Type 4 Tag type 4 is the Security Level Tag Type. Tags of this type are used to label PDUs according
to a hierarchical security level scheme. The set of possible values shall be ordered such that higher
values indicate higher security levels. The set of possible values and the tag length are indicated in the
CSOR. 5.3.5 Security Tag Type 5 Tag type 5 is the Free Form Tag Type. Tags of this type carry a free
format field. This tag may hold character strings, or any other user-defined data. The entry registered in
the CSOR shall indicate the format and interpretation for the information in this tag.
Appendix A: Standard Security Label Encoding for the Network and
Transport Layers (Normative)
A.1 Local Acronyms and Definitions LI - Acronym for Length Indicator. Length Indicator - This field
indicates the length of the Security Information field of a label. Security Label Indicator field - This
field identifies the information that follows as a security label. Security Tag Length field - Gives the
length in octets of the information in a tag. Security Tag Type field - Identifies which kind of tag
follows. TL - Acronym for Security Tag Length field. Tag Set Length field - Gives the length in octets
of the security tag set that follows. A.2 Security Label Format Figure A.1 shows the security label
format for use at the Network and Transport Layers. This figure identifies three fields: Security Label
Indicator, Length Indicator, and Registered Field Set.
ZDDDDDDDDDDDDDBDDDDDDDDDDDDDBDDDDDDDDDDDDDDD? 3 Security 3 Length 3
Registered 3 3 Label 3 Indicator 3 Field Set 3 3 Indicator 3 3 3 3 C0 (hex) 3 3 3
@DDDDDDDDDDDDDADDDDDDDDDDDDDADDDDDDDDDDDDDDDY 1 octet 1 octet Var
Security Label Format Layers 3 and 4 Figure. A.1 A.3 Security Label Indicator The size of the Security
Label Indicator field is 1 octet. Its value is 1100 0000 (C0 hex). A.4 Length Indicator The size of the
Length Indicator (LI) field is 1 octet. Its value is the total length of the Registered Field Set, Security
Label Indicator, and Length Indicator in octets. The maximum value of the LI is 255. A.5 Registered
Field Set One or more Registered Fields are carried in a single label. At this level, every Registered
Field is an ordered set of the following: Tag Set Name Length, a Tag Set Name, Tag Set Length, and
Security Tags. Figure A.2 depicts a Register Field. ZDDDDDDDD Security Tag Set DDDDD?
ZDDDDDDDDDD?ZDDDDDDDDDD?ZDDDDDDDDDD?ZDDDDDDDDDDBDD D D D
DDBDDDDDDDDDD? 3 Tag Set 33 Tag Set 33 Tag 33 Security 3 3 Security 3 3 Name 33 Name 33
Set 33 Tag 3 3 Tag 3 3 Length 33 33 Length 33 3 3 3
@DDDDDDDDDDY@DDDDDDDDDDY@DDDDDDDDDDY@DDDDDDDDDDADD D D D
DDADDDDDDDDDDY 1 octet Var 1 octet Var Registered Field Figure A.2 A.5.1 Tag Set Name
Length The size of the Tag Set Name (TSN) Length field is 1 octet. Its value is the length of the TSN
in octets plus 1. The sum of the values of all the TSN Lengths and TSLs shall equal the value of the LI.
A.5.2 Tag Set Name The Tag Set Name (TSN) is a variable-size field containing the value portion of
the numerical object identifier for the label definition registered in the Computer Security Objects
Register (CSOR). The Numeric Name assigned by the CSOR is encoded according to the Basic
Encoding Rules (BER) [5] rules for Object Identifiers. The registered definition provides the semantics
for the Security Tag Set in the Registered Field. A.5.3 Tag Set Length The size of the Tag Set Length
(TSL) field is 1 octet. Its value is the total length, in octets, of the tags in the set plus 1. This length
field makes it possible to skip over an unrecognized Registered Field when scanning a label. The sum
of the values of all the TSN Lengths and TSLs shall equal the value of the LI. A.5.4 Security Tags The
security information is conveyed using Security Tags. The type, number, usage, and interpretation of
the security tags are given by the CSOR. The Tag Set Name points to a label definition in the CSOR.
Each Security Tag has one-octet type and length fields plus a variable size information field. A.5.4.1
Security Tag Type The size of the Security Tag Type field is 1 octet. Its value indicates the tag type.
Values range between 0 and 255. This standard defines tag types 1 through 5. All other tag types are
reserved for definition by NIST. At least one tag must be present in every Registered Field. A.5.4.2
Security Tag Length The size of the Security Tag Length (TL) is 1 octet. Its value is the length, in
octets, of the information in the tag plus 2 (for the length of the Type and Length fields). Its value
ranges between 2 and 250 octets. The sum of all the TL values in a Registered Field shall equal the
value of the TSL. A.5.4.3 Security Information This variable length field contains the value of the
Security Tag. This standard describes this field for Tag Types 1 - 5. All other tag types are reserved for
later definition by NIST. A.5.4.3.1 Security Tag Type 1 Security tags of this type carry a bit map of
security attributes. The complete set of possible attributes is represented with the bit values off and on
set as appropriate. The interpretation of bit values in a bit map is given by the CSOR. Bits in the map
shall be numbered starting with the most significant bit of the first transmitted octet (bit 0). Bit maps
shall be padded to the right (i.e., up to the least significant bit of the last octet), if necessary. The format
of this tag type is as follows: 0123 ... ZDDDDDDDDDDDDBDDDDDDDDDDDDBDDDDDDD D D
DDDDDD? 3 00000001 3 LLLLLLLL 3 BBBB BBBB 3
@DDDDDDDDDDDDADDDDDDDDDDDDADDDDDDD D D DDDDDDY Tag Type Tag Length
Bit Map Security Tag Type 1 Figure A.3 A.5.4.3.2 Security Tag Type 2 Tag Type 2 is used when only
a few security attributes out of a large set need to be singled out for a PDU. This is done by
enumerating the attributes that apply (set inclusion), or do not apply (set exclusion). This enumeration
shall start with the lowest numbered attribute following an ascending order. Valid TL field values for
this tag type are multiples of 2. The CSOR will indicate whether attributes enumerated in a type 2 tag
will be interpreted as included or excluded from the applicable set. A single tag may enumerate several
security attributes, assigning 2 octets per attribute. The attributes enumerated may be between 0 and
65535. The format of this tag type is as follows:
ZDDDDDDDDDDDDBDDDDDDDDDDDDBDDDDDDD D D DDDDDDD? 3 00000010 3
LLLLLLL0 3 AA AA AA AA 3 @DDDDDDDDDDDDADDDDDDDDDDDDADDDDDDD D D
DDDDDDDY Tag Type Tag Length Enumerated Attributes Security Tag Type 2 Figure A.4 A.5.4.3.3
Security Tag Type 3 Tag Type 3 is used when all the security attributes between certain lower and
upper bound need to be singled out for a PDU. This is done by indicating the higher-numbered and
lower-numbered attributes as bounds for the range. Valid length (TL) field values for this tag type are
multiples of 2. The CSOR will indicate whether attributes in a range will be interpreted as included or
excluded from the applicable set. A single tag may indicate multiple security attribute ranges. These
ranges shall be listed in descending numerical order and shall not overlap. Each bound attribute is
indicated by a 2-octet binary number. The final lower bound may be omitted if its value is 0. Security
attributes are identified by integers between 0 and 65535. The format of this tag type is as follows:
ZDDDDDDDDDDDDBDDDDDDDDDDDDBDDDDDD D D DDDDDD? 3 00000011 3 LLLLLLL0
3 UUUU DDDD 3 @DDDDDDDDDDDDADDDDDDDDDDDDADDDDDD D D DDDDDDY Tag
Type Tag Length Range Set Security Tag Type 3 Figure A.5 A.5.4.3.4 Security Tag Type 4 Tag type 4
carries a security level indicator. Possible values are non-negative integers. The set of possible levels
shall be assigned such that higher values indicate higher security levels. The set of possible values and
the tag length are indicated in the CSOR. The format of this tag type is as follows:
ZDDDDDDDDDDDDBDDDDDDDDDDDDBDDDDDD D D DDDDDD? 3 00000100 3 LLLLLLLL
3 SSSS SSSS 3 @DDDDDDDDDDDDADDDDDDDDDDDDADDDDDD D D DDDDDDY Tag
Type Tag Length Security Level Security Tag Type 4 Figure A.6 A.5.4.3.5 Security Tag Type 5 Tag
type 5 carries a free format field of up to 248 octets. The information field of this tag may hold
character strings, or any user-defined data. The format of this tag type is as follows:
ZDDDDDDDDDDDDBDDDDDDDDDDDDBDDDDD D D DDDDD? 3 00000101 3 LLLLLLLL 3
FFFF FFFF 3 @DDDDDDDDDDDDADDDDDDDDDDDDADDDDD D D DDDDDY Tag Type Tag
Length Free Form Field Security Tag Type 5 Figure A.7 A.6 Usage Rules Throughout this appendix it
is assumed that the leftmost bit is the most significant bit (MSB). The MSB, labeled bit 0, is always
transmitted first. All illustrated fields are transmitted from left to right. FIPS PUB 171, 1992 APRIL 27
FIPS PUB 171, 1992 APRIL 27
Federal Information Processing Standards Publication 171
U.S. DEPARTMENT OF COMMERCE, Barbara Hackman Franklin, Secretary NATIONAL
INSTITUTE OF STANDARDS AND TECHNOLOGY John W. Lyons, Director
Foreword
The Federal Information Processing Standards Publication Series of the National Institute of Standards
and Technology (NIST) is the official series of publications relating to standards and guidelines
adopted and promulgated under the provisions of Section 111(d) of the Federal Property and
Administrative Services Act of 1949 as amended by the Computer Security Act of 1987, Public Law
100-235. These mandates have given the Secretary of Commerce and NIST the responsibilities for
improving the utilization and management of computer and related telecommunications systems in the
Federal Government. The NIST, through its Computer Systems Laboratory, provides leadership,
technical guidance, and coordination of Government efforts in the development of standards and
guidelines in these areas. Comments concerning Federal Information Processing Standards
Publications are welcomed and should be addressed to the Director, Computer Systems Laboratory,
National Institute of Standards and Technology, Gaithersburg, MD 20899. James H. Burrows, Director
Computer Systems Laboratory
Abstract
This standard specifies a particular selection of options for the automated distribution of keying
material by the Federal Government when using the protocols of ANSI X9.17. ANSI X9.17 defines
procedures for the manual and automated management of keying materials and contains a number of
options. Systems which are built to conform to all options of ANSI X9.17 are likely to be complex and
expensive. The selected options specified in this standard will allow the development of cost effective
systems which will, in addition, increase the likelihood of interoperability. Key words: ADP security,
computer security, cryptography, Federal Information Processing Standard (FIPS), key management.
Federal Information Processing Standards Publication 171 1992 April 27
Announcing the Standard for KEY MANAGEMENT USING ANSI
X9.17
Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National
Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant to
Section 111(d) of the Federal Property and Administrative Services Act of 1949 as amended by the
Computer Security Act of 1987, Public Law 100-235. 1. Name of Standard. Key Management Using
ANSI X9.17 (FIPS PUB 171). 2. Category of Standard. Computer Security Standard; Cryptography. 3.
Explanation. ANSI X9.17-1985, Financial Institution Key Management (Wholesale), is a voluntary
industry standard that defines procedures for the manual and automated management of the data (e.g.,
keys and initialization vectors) necessary to establish and maintain cryptographic keying relationships.
This data is known as keying material. ANSI X9.17 specifies the minimum requirements for: o Control
of the keying material during its lifetime to prevent unauthorized disclosure, modification or
substitution; o Distribution of the keying material in order to permit interoperability between
cryptographic equipment or facilities; o Ensuring the integrity of keying material during all phases of
its life, including its generation, distribution, storage, entry, use and destruction; and o Recovery in the
event of a failure of the key management process or when the integrity of the keying material is
questioned. ANSI X9.17 utilizes the Data Encryption Standard (DES) to provide key management
solutions for a variety of operational environments. As such, ANSI X9.17 contains a number of
options. Systems which are built to conform to all options of ANSI X9.17 are likely to be complex and
expensive. This document adopts ANSI X9.17-1985 and specifies a particular selection of options for
the automated distribution of keying material by the Federal Government using the protocols of ANSI
X9.17. Interoperability between systems built to conform to this selection of options will be more
likely, and the cost of building and testing such systems will be reduced. However, less restrictive
implementations may be used as long as the necessary restrictions can be effected when used for
Federal Government applications. 4. Approving Authority. Secretary of Commerce. 5. Maintenance
Agency. U.S. Department of Commerce, National Institute of Standards and Technology (NIST),
Computer Systems Laboratory. 6. Cross Index. a. FIPS PUB 1-2, Code for Information Interchange, Its
Representations, Subsets, and Extensions. b. FIPS PUB 46-1, Data Encryption Standard. c. FIPS PUB
81, DES Modes of Operation. d. FIPS PUB 113, Computer Data Authentication. e. FIPS PUB 161,
Electronic Data Interchange (EDI). f. ANSI X9.17-1985, Financial Institution Key Management
(Wholesale). g. ANSI X9.9, Financial Institution Message Authentication (Wholesale). h. Federal
Information Resources Management Regulations subpart 201-20.303, Standards, and subpart 20139.1002, Federal Standards. Other FIPS and Federal Standards may be applicable to the
implementation and use of this standard. A list of currently approved FIPS may be obtained from the
National Institute of Standards and Technology, Computer Systems Laboratory, Gaithersburg, MD
20899. 7. Objectives. The objective of this standard is to provide an interoperable key management
system when the protocols of ANSI X9.17 are used, and the same option set is selected. The options
selected in this standard were chosen with regard to the degree of cryptographic protection that can be
provided for the data with which the keys will be used, as well as a decision to reduce the complexity
and cost of ANSI X9.17 implementations by limiting the number of options which are implemented
and tested. 8. Applicability. This standard shall be used by Federal departments and agencies when
designing, acquiring, implementing and managing keying material using the manual and automated
procedures of ANSI X9.17. In the future, other key management methods may be approved by NIST
for Federal Government use (e.g., public key based key management methods). In addition, this
standard may be adopted and used by non-Federal Government organizations. Such use is encouraged
when it is either cost effective or provides interoperability for commercial and private organizations. 9.
Applications. This standard, along with ANSI X9.17, provides a key management system for: o a
Point-to-Point environment in which each party to a key exchange shares a key encrypting key which
is used to distribute other keys between the parties, o a Key Distribution Center environment in which
each party shares a key encrypting key with a center who generates keys for distribution and use
between pairs of parties, and o a Key Translation Center environment in which each party shares a key
encrypting key with a center who translates keys generated by one party which will be distributed to
another party, the ultimate recipient. 10. Implementations. This standard covers key management
implementations which may be in software, hardware, firmware or a combination thereof. Key
management implementations that are validated by NIST will be considered as complying with this
standard. Information about the key management validation program can be obtained from the
National Institute of Standards and Technology, Computer Systems Laboratory, Gaithersburg, MD
20899. 11. Specifications. The specifications for Federal Information Processing Standard (FIPS) 171,
Key Management Using ANSI X9.17, (affixed) are contained in ANSI X9.17-1985, Financial
Institution Key Management (Wholesale), as modified by the technical specification section of this
document. 12. Implementation Schedule. This standard becomes effective October 30, 1992. 13.
Export Control. Certain cryptographic devices and technical data regarding them are deemed to be
defense articles (i.e., inherently military in character) and are subject to Federal Government export
controls as specified in Title 22, Code of Federal Regulations, Parts 120-128. Some exports of
cryptographic modules conforming to this standard and technical data regarding them must comply
with these Federal regulations and be licensed by the Office of Defense Trade Controls of the U.S.
Department of State. Other exports of cryptographic modules conforming to this standard and technical
data regarding them fall under the licensing authority of the Bureau of Export Administration of the
U.S. Department of Commerce. The Department of Commerce is responsible for licensing
cryptographic devices used for authentication, access control, proprietary software, automatic teller
machines (ATMs), and certain devices used in other equipment and software. For advice concerning
which agency has licensing authority for a particular cryptographic device, please contact the
respective agencies. 14. Patents. Cryptographic devices used to implement this standard and ANSI
X9.17 may be covered by U.S. and foreign patents. 15. Waiver Procedure. Under certain exceptional
circumstances, the heads of Federal departments and agencies may approve waivers to Federal
Information Processing Standards (FIPS). The head of such agency may redelegate such authority only
to a senior official designated pursuant to Section 3506(b) of Title 44, U.S. Code. Waivers shall be
granted only when: a. compliance with a standard would adversely affect the accomplishment of the
mission of an operator of a Federal computer system, or b. cause a major adverse financial impact on
the operator which is not offset by Governmentwide savings. Agency heads may act upon a written
waiver request containing the information detailed above. Agency heads may also act without a written
waiver request when they determine that conditions for meeting the standard cannot be met. Agency
heads may approve waivers only by a written decision which explains the basis on which the agency
head made the required finding(s). A copy of each such decision, with procurement sensitive or
classified portions clearly identified, shall be sent to: National Institute of Standards and Technology;
ATTN: FIPS Waiver Decisions, Technology Building, Room B-154; Gaithersburg, MD 20899. In
addition, notice of each waiver granted and each delegation of authority to approve waivers shall be
sent promptly to the Committee of Government Operations of the House of Representatives and the
Committee on Governmental Affairs of the Senate and shall be published promptly in the Federal
Register. When the determination on a waiver applies to the procurement of equipment and/or services,
a notice of the waiver determination must be published in the Commerce Business Daily as a part of
the notice of solicitation for offers of an acquisition or, if the waiver determination is made after that
notice is published, by amendment to such notice. A copy of the waiver, any supporting documents,
the document approving the waiver and any supporting and accompanying documents, with such
deletions as the agency is authorized and decides to make under 5 U.S.C. Section 552(b), shall be part
of the procurement documentation and retained by the agency. 16. Where to Obtain Copies. Copies of
this publication are for sale by the National Technical Information Service, U.S. Department of
Commerce, Springfield, VA 22161. (Sale of the included specifications document is by arrangement
with the American Bankers Association.) When ordering, refer to Federal Information Processing
Standards Publication 171 (FIPSPUB171), and title. Payment may be made by check, money order,
credit card or NTIS deposit account. Federal Information Processing Standard Publication 171 1992
April 27
Specifications for KEY MANAGEMENT USING ANSI X9.17
INTRODUCTION
ANSI X9.17-1985, Financial Institution Key Management (Wholesale), is a voluntary standard that
utilizes the Data Encryption Standard (DES) to provide key management solutions for a variety of
operational environments. As such, ANSI X9.17 contains a number of options. Systems which are built
to conform to all options of ANSI X9.17 are likely to be complex and expensive. This document
adopts ANSI X9.17 and specifies a particular selection of options for the automated distribution of
keying material by the Federal Government using the protocols of ANSI X9.17. Interoperability
between systems built to conform to this selection of options will be more likely, and the cost of
building and testing such systems will be reduced. It is assumed that the reader of this standard is
familiar with ANSI X9.17.
OPTIONS SELECTED FOR FEDERAL GOVERNMENT USE
This standard discusses 27 of the options which are provided in ANSI X9.17. In this section, each
option is numbered and listed, its use in ANSI X9.17 is described, the selection for Federal
Government use is specified along with any other additional requirements, and a brief justification for
the selection is provided. Underlined bold face type and the use of the word "shall" are used to indicate
mandatory requirements. The use of the word "should" is used to indicate recommendations.
1 ROLE ASSUMED BY A PARTY TO A KEY EXCHANGE
USE IN ANSI X9.17: Party A is responsible for sending keys to the other party. Party B is the receiver
of those keys. A party to a key exchange may assume the role of either Party A or Party B.
Implementations may be designed to (1) always assume the role of Party A, (2) always assume the role
of Party B, or (3) assume either role. Implementations which assume the role of Party A in the PTP or
CKT environments must be able to generate or otherwise acquire keys (and optionally an IV) and send
the keys (and IV) in a KSM. Implementations which assume the role of Party A in the CKD
environment requests keys (and an IV) from a CKD (see Option 23). Implementations which assume
the role of Party A in the CKT or CKD environments must be able to communicate directly with a
CKD or CKT. Implementations which assume the role of Party B in any of the environments must be
able to receive keys (and an IV) in a KSM. SELECTION FOR FEDERAL GOVERNMENT USE: The
role(s) which may be assumed by an equipment is optional. The information management needs of an
organization or agency will in large measure determine the roles to be assumed by the equipment.
Implementations which offer both roles offers greater flexibility, but is more costly. Implementations
which offer a single role is restricted to that role, and can only communicate with parties which can
assume the opposite role.
2 RSI FROM PARTY B TO PARTY A
USE IN ANSI X9.17: In the event that a party does not have the capability to generate or otherwise
acquire keys (and an IV) or it is deemed advisable not to do so, an RSI permits that party (assuming the
role of Party B) to request that another party (assuming the role of Party A) generate or otherwise
acquire the keys (and IV) and send them in a KSM. Note that a Party A may also send keys (and an IV)
to a Party B without receiving an RSI from Party B. SELECTION FOR FEDERAL GOVERNMENT
USE: The implementation and use of RSIs from Party B to Party A is optional. There may be
applications where Party B will be required to let Party A know that keys (and an IV) are needed. There
may be other applications where Party B may not need to request keys, and RSI's will not be used.
3 SVR SUBFIELD ORDERING
Use in ANSI X9.17: When an RSI is sent, it contains an SVR field. One KD is implicitly requested. A
second KD, an IV, and/or a (*)KK may be requested by including subfields in the SVR field (except in
the CKD environment. The ordering of these subfields is unspecified, although an ordering is shown in
the examples of key field formats. SELECTION FOR FEDERAL GOVERNMENT USE: When the
subfields of the SVR field are used, it is mandatory that the ordering of subfields be as follows: *KK
(requests key encrypting key pair) KD (requests second data key) IV (requests Initialization Vector)
For example, SVR/*KK.KD.IV requests a *KK, two KDs and an IV. The selection of a fixed ordering
simplifies implementation and improves interoperability.
4 EDC FIELD IN THE RSI AND ESM
USE IN ANSI X9.17: The error detection code (EDC) is a Message Authentication Code (MAC)
computed on a message using a fixed, publicly known key. An EDC field is an optional field in RSI
and ESM messages. The EDC field may be appended to these messages to aid in the detection of errors
missed by network error handling protocols. Upon receiving an RSI or ESM with an EDC field, a
recipient who does not implement the EDC option may choose to either respond with an ESM
containing an "O" (option not implemented) in the ERF field, or may simply ignore the EDC field.
SELECTION FOR FEDERAL GOVERNMENT USE The implementation and use of EDC fields in
RSIs and ESMs is mandatory. EDCs provide a simple automated means of detecting errors missed by
network error-handling protocols. An EDC is easy to compute using an existing feature of the
cryptographic system (i.e., the MAC computation). Since the use of EDCs is mandatory, the recipient
of an RSI or ESM with an EDC field must process the field. The sending of an ESM in response to an
ESM with an EDC error is forbidden.
5 GENERATE OR OTHERWISE ACQUIRE KEYS AND AN IV
USE IN ANSI X9.17: During a key exchange, new keys and IVs may be either generated or otherwise
acquired by Party A in the PTP and CKT environments. In the CKD environment, Party A may request
keys and IVs from the CKD, who either generates or otherwise acquires them. Alternatively, the CKD
may send unsolicited keys and IVs to Party A which have been generated or otherwise acquired.
SELECTION FOR FEDERAL GOVERNMENT USE: The choice of whether to generate or otherwise
acquire keys and IVs is optional. The generation of keys is the most sensitive of all COMSEC
functions. Any inadequacies in the implementation of the key generation function or in the physical
security safeguards of that function will seriously undermine the security of the cryptographic
mechanisms. It is imperative that the physical security measures implemented to protect the key
management facility be designed to restrict access to both the key generation system and the keys
generated therein. These measures are necessary to prevent unauthorized disclosure, insertion and
deletion of the system or keys produced by the system. The provisions of ANSI X9.17-1985
paragraphs 3.2, 3.4.2 and 5.2 should be fully considered in the design and operation of the key
management facility. There may be some applications where the generation of keys may be desirable,
and other applications where the distribution of keys from another source (e.g., a central authority) may
be desirable, depending on the desired management structure.
6 KEY GENERATION TECHNIQUE
USE IN ANSI X9.17: Cryptographic keys may or may not be generated by each party. ANSI X9.17
does not specify the method to be used for key generation, but does supply a key generation technique
in Appendix C which may be used. SELECTION FOR FEDERAL GOVERNMENT USE: Only NIST
approved key generation algorithms (e.g., the technique defined in Appendix C of ANSI X9.17) shall
be used. The generation of keys is the most sensitive of all cryptographic functions. Any inadequacies
in the implementation of the key generation function or in the physical security safeguards of that
function will seriously undermine the integrity of other cryptographic mechanisms.
7 KEY NAMING
USE IN ANSI X9.17: When one or more keys are shared between two parties, the standard provides a
means for naming the keys. The IDK1 subfield of a key field may be used to name that key. The IDK2
subfield of a key field may be used to name the key encrypting key used to encrypt the key transmitted
in that field. The IDD and IDA fields of a DSM, and the IDD field of an RSM to a DSM identify keys
to be discontinued. If one and only one key of a particular type ((*)KK or KD) is shared between two
parties, then that key does not have to be named. If the key is not named, then the IDK1 and IDK2
subfields are NULL, and the IDA field is omitted. Keys of different types (i.e., a *KK and a KD) may
have the same name. Two data keys with the same name may be sent in the same message. The first
data key is to be used for authentication, and the second is to be used for encryption. SELECTION
FOR FEDERAL GOVERNMENT USE: It is mandatory that: o All keys are named, even if one and
only one key of that type is shared. o All keys of a particular type (i.e., *KK or KD) which are shared
at any given time between two parties must be uniquely named. o Key names (i.e., in IDK1, IDK2,
IDD, and IDA fields) must be used in CSMs whenever keys are sent or referenced, even if one and
only one key of that type is shared. o If an unnamed key is received in a CSM and it is permissible to
respond to the CSM with an ESM, then an ESM must be returned with a "C" (cannot process) in the
ERF field (see Option 18). The use of key names, even when one and only one key of a particular type
is shared, simplifies implementations and operations. The use of key names is a means of eliminating
ambiguities during use and storage of a key, and aids in the message reconstruction at a later time. It is
also mandatory that: o Two KD's within a single KSM must not have the same name. o A manually
transmitted key must be identified by placing the name for that key on the material itself and on the
package (e.g., envelope) used to provide confidentiality protection for the keys. The outer security
wrapping should not contain this identification. It is highly recommended that all keys, regardless of
type, which are shared between a communicating pair be uniquely named. This implies that a key
cannot be replaced by a key of the same name (and type), but must always be deleted by a DSM.
However, it allows all keys, even discontinued and archived keys, to be easily identified by their name
alone. It is also recommended that a structured and consistent naming convention be used within a
network, department, or agency. Such a convention may be of great long term benefit in key
management, audit, and in the conduct of investigations.
8 KEY AND FACILITY IDENTIFIER CHARACTER SETS
USE IN ANSI X9.17: Each facility identifier (e.g., the contents of the ORG, RCV, IDU, and IDC
fields) consists of 4 to 16 characters (inclusive). Key identifiers (e.g., contained in the IDK1 and IDK2
subfields and the IDD and IDA fields) consist of up to 16 characters. The character set for these
identifiers has not been precisely defined, however. Several characters have been defined in the
standard as delimiters or otherwise reserved for special use. These are: period (.), blank (), solidus (/),
open and close parentheses ("(" and ")"), carriage return (CR) and line feed (LF). Additionally, the
asterisk (*) is used to designate key encrypting key pairs in the ANSI X9.17 standard, and it is used to
indicate a failed MAC in the ANSI X9.9 standard. While the ANSI X9.17 standard restricts the use of
the period and blank within fields and subfields, and hence, in key and facility identifiers, there is
doubt as to whether the remaining characters should be allowed in these identifiers. SELECTION FOR
FEDERAL GOVERNMENT USE: Three characters in addition to the period and blank are forbidden
in facility and key identifier fields and subfields because they may cause confusion. These characters
are the asterisk, carriage return, and line feed. The other characters used for special purposes (i.e., the
solidus and the open and close parentheses) may be used since they do not cause any confusion. The
implementation and use of a standardized and unambiguous character set will allow greater
interoperability.
9 KEY ENCRYPTING KEY LENGTH
USE IN ANSI X9.17: The standard permits manual key encrypting keys shared between two parties to
be either single key encrypting keys (KKs) or key encrypting key pairs (*KKs). Manual keys shared
between a party and a center must be *KKs. In the PTP and CKT environments, the standard permits
two parties to exchange either KKs or *KKs. SELECTION FOR FEDERAL GOVERNMENT USE:
The use of *KKs is mandatory for manual key encrypting keys shared between two parties in the PTP
environment, and for new key encrypting keys exchanged between two parties in the PTP and CKT
environments. The use of KKs is forbidden. The use of *KKs may: o allow for longer cryptoperiods, o
provide more security, o substantially reduce the requirements for operators to enter new manual key
encrypting keys, o reduce the number of errors which occur during the manual entry of keys because of
the less frequent need to enter *KKs, and o result in lowered overall communications costs.
10 NOTARIZATION OF KEYS
USE IN ANSI X9.17: In the CKT and CKD environments, the notarization of keys is required in RTRs
generated by the centers. Notarization is also used in the subsequent KSMs. However, in the PTP
environment, the notarization of keys is optional in KSMs generated by Party A. SELECTION FOR
FEDERAL GOVERNMENT USE: The implementation and use of notarization in the PTP
environment is mandatory. Notarization improves security and can provide a digital signature
capability when properly implemented in physically secure modules.
11 SENDING KEY ENCRYPTING KEYS IN A KSM IN THE PTP ENVIRONMENT
USE IN ANSI X9.17: In the PTP environment, Key Service Messages (KSMs) may carry an
automatically distributed key encrypting key ((*)KK) in addition to one or two KDs and possibly an
IV. The (*)KKs may be used to encrypt KDs in subsequent messages which do not contain (*)KKs.
Alternatively, systems may be designed which never carry (*)KKs in KSMs, but only carry one or two
KDs and,optionally, an IV. SELECTION FOR FEDERAL GOVERNMENT USE: The sending of a
*KK in KSMs in the PTP environment is optional. The sending of a *KK in a KSM and its subsequent
use in sending KDs in other messages may reduce the use and exposure of the manually distributed
*KKs. The operational needs of an organization will in large measure determine whether or not the
option is used. Implementations which use the option will provide greater flexibility.
12 SEND EITHER ONE OR TWO DATA KEYS
USE IN ANSI X9.17: Either one or two data keys (KDs) may be contained in KSM, RFS or RTR
messages. At least one KD is always present. SELECTION FOR FEDERAL GOVERNMENT USE:
The sending of two KDs in a KSM (all environments) or an RTR (CKD environment) is optional.
Without the option of sending two data keys (which is a major feature of the standard), equipment will
lack the ability to distribute data keys for both authentication and encryption within a single key
exchange. The sending of two KDs in an RFS or RTR (CKT environment) is disallowed in accordance
with Option 26.
13 SEND ODD PARITY ON KEYS
USE IN ANSI X9.17: The standard requires that all manually transmitted and entered plaintext keys
have odd parity. The plaintext form of automatically transmitted keys may optionally have odd parity.
SELECTION FOR FEDERAL GOVERNMENT USE: The use of odd parity on the plaintext form of
all keys, whether manually entered or automatically transmitted, is mandatory in order to provide
interoperability.
14 SEND INITIALIZATION VECTORS WITH KEYS
USE IN ANSI X9.17: When Party A sends keys in a KSM, an Initialization Vector (IV) may also be
sent. In a CKD environment, an IV may be sent in an RTR message. SELECTION FOR FEDERAL
GOVERNMENT USE: The sending of an IV is optional. If an IV is needed for encryption and is not
reliably transmitted by other means, the presence of an IV is necessary. The inclusion of an IV in a
CSM provides a reliable means of exchanging IVs.
15 ENCRYPTION OF INITIALIZATION VECTORS
USE IN ANSI X9.17: When an IV is sent in a KSM, the encryption of the IV is optional. SELECTION
FOR FEDERAL GOVERNMENT USE: It is mandatory that IVs be encrypted. FIPS 140 requires
encrypted IVs for the CBC mode. The encryption of all IVs simplifies implementation and processing,
and improves security when IVs are transmitted over unprotected channels.
16 SEND EFFECTIVE DATE OF KEY (EDK) WITH KEYS
USE IN ANSI X9.17: When Party A sends keys in a KSM or the CKD sends keys to Party A in an
RTR, the Effective Date of Key (EDK) field may be used to indicate the date and time of key activation
(i.e., the start of the cryptoperiod). SELECTION FOR FEDERAL GOVERNMENT USE: The use of
the EDK field is optional. The use of the EDK field will permit the exchange of keys prior to their
activation. This option may be desired for some applications.
17 USE OF DISCONNECT SERVICE MESSAGES
USE IN ANSI X9.17: DSMs may be used to disconnect (i.e., delete) one or more keys, and may be
used to terminate a keying relationship. The DSMs may be used to protect a party in the event of the
compromise of a key or keying material, to terminate a business relationship or simply to reduce the
number of keys that must be stored. When a DSM is sent to request the deletion of keys, the RSM
returned to the party which sent the DSM provides an authenticated response which acknowledges the
receipt of the instruction to delete the key(s); if errors are detected in the reception of the DSM, an
ESM is returned. If the DSM is implemented, the RSM and ESM are required by the standard.
SELECTION FOR FEDERAL GOVERNMENT USE: The implementation of the ability to both send
and receive DSMs is mandatory. It is desirable to have a convenient and reliable automated means to
discontinue keys that are no longer needed or may be suspected of compromise. The use of the DSM
capability is optional for the sender, i.e., other means may be used to discontinue keys.
18 USE OF THE IDA FIELD IN A DSM IF ONLY ONE DATA KEY IS SHARED
USE IN ANSI X9.17: If one and only one KD is shared between two parties, then the identity (name)
of the key for authenticating a Disconnect Service Message (DSM) may or may not be specified in an
IDA field of the DSM. SELECTION FOR FEDERAL GOVERNMENT USE: The use of the IDA field
in a DSM is mandatory, even if one and only one KD is shared between the two parties. This provides
a consistent and interoperable method for generating DSMs.
19 USE "C" AS A GENERAL ERROR CODE IN ESM AND ERS MESSAGES
USE IN ANSI X9.17: A "C" in the ERF field of ESM and ERS messages is a general error code which
may be used when a more specific error code is not appropriate. The "C" indicates an inability to
process the previous message. Another ERF code which may be used is the "F" (format error).
SELECTION FOR FEDERAL GOVERNMENT USE: The use of "C" as a general error code in the
ERF field of an ESM and ERS is mandatory when other error codes are not readily applicable.
20 ACTION WHEN A COUNT ERROR IS REPORTED
USE IN ANSI X9.17: When a CSM (i.e., KSM, RFS, RTR) is received with a count (i.e., CTA, CTB,
CTP) less than the recipient's expected (stored) count, the message is rejected and an ESM is returned
to the originator of the CSM. In the event of a count error in a KSM in a center environment, Party B
returns an ESM to Party A, and Party A sends an ERS to the center. The ESM or ERS includes an
indication of a count error, the count received in the related CSM, and the recipient's expected (stored)
count. Upon receipt of the ESM or ERS indicating a count error, the counters may be resynchronized
by either: (1) automatically adjusting the origination count up to the expected count received in the
ESM or ERS, or (2) replacing (possibly manually) the (*)KK associated with the count in error,
thereby also re-initializing the counters. SELECTION FOR FEDERAL GOVERNMENT USE: It is
mandatory that automatic adjustment of the counters be attempted at least once upon receipt of an ESM
or ERS reporting a count error in a previously received CSM. In the event that this first attempt to
automatically adjust the counters does not correct the error, then subsequent attempts to correct the
error may either be (1) to adjust the counters automatically, or (2) to replace the associated *KK. If the
associated *KK is replaced, and an organization has a security officer or an individual designated as
crypto custodian, that individual should be notified immediately. All attempts to resynchronize
counters manually should be logged. The organization responsible for the auditing should be notified
of such attempts. Automatic resynchronization of counters may eliminate the need for human
intervention (e.g., manual distribution and entry of new *KKs) and the errors induced by this process.
21 USE "CRLF" AS A CSM FIELD DELIMITER
USE IN ANSI X9.17: Normally, the field delimiter in CSMs is a blank (). In order to improve the
readability of CSMs displayed on a screen or hard copy listing, the field delimiter may be a blank
followed by a carriage return and line feed (CRLF). SELECTION FOR FEDERAL GOVERNMENT
USE: The use of a "CRLF" as the field delimiter in CSMs is forbidden. The use of the "CRLF" may
adversely affect interoperability. As the standard was originally written, it referenced ANSI X9.9-1982
and defined the MAC such that the "CRLF" would be edited out before CSM authentication. However,
when ANSI X9.9-1986 was revised, it required that all characters in the CSM be utilized in the
authentication process. Therefore, the use of "CRLF" is not compatible with the use of only a "".
22 LOGGING OF A CSM
USE IN ANSI X9.17: This option is referenced in the standard in the table for processing counters. The
table indicates that logging is mandatory when counts disagree, whereas logging is optional when the
counts agree. There is no indication of what information is to be logged. SELECTION FOR FEDERAL
GOVERNMENT USE: The logging of all CSMs is mandatory. Logging is a prudent accounting and
control practice.
23 USE OF CENTERS (CKD AND CKT)
USE IN ANSI X9.17: A CKD is used to generate or otherwise acquire keys and IVs when a party
cannot or may not be allowed to perform this process. A CKT is used to translate keys for a party with
whom the requesting party does not share an appropriate (*)KK (i.e., a manually distributed (*)KK if
(*)KKs are to be sent, otherwise a manually or automatically distributed (*)KK). SELECTION FOR
FEDERAL GOVERNMENT USE: The use of centers is optional. In large networks, the use of centers
reduces procedural problems and the operational costs of manual entry. Centers are used to reduce the
operational and security problems inherent in the manual distribution of large numbers of keys. Their
use does not reduce the number of keys that must be sent (by whatever means), but provides an
electronic mechanism that substitutes for costly and inefficient manual key distribution (e.g., by a
courier service).
24 RSI FROM PARTY A TO A CKD
USE IN ANSI X9.17: In the Key Distribution Center (CKD) environment, an RSI allows Party A to
request that the CKD generate or otherwise acquire data keys and IVs and send them to Party A in a
Response-To-Request (RTR) message. Note that the CKD may send the data keys and IVs to Party A
without receiving an RSI from Party A (i.e., send an unsolicited RTR) (see Option 24). SELECTION
FOR FEDERAL GOVERNMENT USE: The use of RSIs from Party A to the CKD is optional. If Party
A must use a CKD to get keys and IVs when Party A determines that they are needed, then the RSI
provides an automated method of doing so.
25 UNSOLICITED RESPONSE TO REQUEST (RTR) MESSAGES
USE IN ANSI X9.17: In the Key Distribution Center (CKD) environment, a request for keys may be
initiated by Party A. Alternatively, in an unsolicited action, the CKD can send keys to Party A for Party
A to use in establishing a keying relationship with Party B. The CKD sends one or two KD(s) for Party
A, and sends the same keys as KDU(s) for Party A to forward to Party B. An optional IV may be
included. The use of the unsolicited RTR provides a centralization of control over key generation and
acquisition as well as the timing of key exchanges. SELECTION FOR FEDERAL GOVERNMENT
USE: The use of unsolicited RTRs is optional. The use of the unsolicited RTR will reduce
communications costs by eliminating the use of the RSI from Party A to the CKD and will allow the
CKD to control the timing of key exchanges.
26 SEND (*)KK OR KD TO A CKT FOR TRANSLATION
USE IN ANSI X9.17: In the CKT environment, Party A may generate or otherwise acquire and send
one or two KDs in a RFS to a CKT for translation, notarization, and return as one or two KDUs for
forwarding to Party B. Alternatively, Party A may generate or otherwise acquire and send a (*)KK in
an RFS to a CKT for translation, notarization, and return as a (*)KKU for forwarding to Party B. In the
latter case, a KD is also sent in the RFS message which is used only for message authentication of the
RFS and the responding RTR message. SELECTION FOR FEDERAL GOVERNMENT USE: In the
CKT environment, it is mandatory that Party A only send *KKs in an RFS message to a CKT for
translation and notarization. The translation of one or two KDs may not be requested. This restriction
significantly reduces the load on the CKT since the parties to the exchange may then enter a PTP mode
to send KDs.
27 USE OF A COUNT WINDOW
USE IN ANSI X9.17: In the CKD and CKT environments, it is possible for a recipient to receive
CSMs whose counts are out of sequence, yet the MACs in these CSMs indicate that the messages are
authentic. A recipient of these CSMs may establish a window which represents a range of reception
counter values such that the corresponding CSMs, should they arrive out of sequence, shall be
accepted without declaring an error. Appendix F of ANSI X9.17 describes a method of defining and
managing such a window. SELECTION FOR FEDERAL GOVERNMENT USE: The use of the
window technique described in Appendix F of ANSI X9.17 is mandatory in the CKD and CKT
environments. It is desirable to have a uniform window technique for Federal Government use. The use
of the window technique in Appendix F of ANSI X9.17 in the CKD and CKT environments will
permit interoperabilty. Note that when the window size is equal to one, the window technique
functions as if no window technique was present. However, the implemented window technique shall
allow for a window size greater than one to be used. TABLE I SUMMARY OF OPTIONS AND
SELECTIONS: ALL ENVIRONMENTS Option Section(s) Description Federal Impact(s) Number of
ANSI of Option Government X9.17 Use 1 8.6.2 Role Optional Implementing both 8.6.3 assumed by
roles provides 8.6.4 a party to flexibility a key exchange 2 8.2 RSIs from Optional Implementation
8.6.2 Party B to provides Party A flexibility 3 Table II SVR Defined Simplifies subfield order is
implementation; ordering mandatory improves interoperability 4 7.2.8 EDC in Mandatory Automated
means RSIs and of detecting errors ESMs 5 8.6.2 Generate Optional Implementation 5. or otherprovides autonomy; wise acquire no generation or keys and IVs acquisition capability 6 5. Key As
defined Provides required 5.3 generation in Appendix randomness technique C 7 Table II Key naming
Mandatory Eliminates (see Option ambiguities; allows 6) a better journaling capability 8 8.3 Key and
Mandated Eliminates 8.4 facility per Option ambiguities; 8.5 identifier 7 improves Table II character
interoperability sets 13 Table II Send odd Mandatory Improves parity on interoperability keys TABLE
I (Cont'd). SUMMARY OF OPTIONS AND SELECTIONS: ALL ENVIRONMENTS Option
Section(s) Description Federal Impact(s) Number of ANSI of Option Government X9.17 Use 14 8.6.2
Send IVs Optional Provides a reliable 8.6.3 with keys means of 8.6.4 transmitting an IV 15 7.2.6
Encrypt Mandatory Simplifies IVs implementation since encryption requires encrypted IVs 16 Table II
Send EDKs Optional Permits the with keys exchange of keys prior to activation 17 8.2 Use of
Mandatory Automated, 8.6.4 DSMs convenient and reliable means of discontinuing keys 18 Table II
Use of the Mandatory Provides IDA field interoperability in a DSM if only one data key is shared 19
Table II Use "C" as Mandatory Eliminates a general confusion error code in an ESM and ERS 20 7.3.3
Action Mandatory Eliminates the need when a for one for human count attempt to intervention error is
adjust reported before sending new keys TABLE I (Cont'd). SUMMARY OF OPTIONS AND
SELECTIONS: ALL ENVIRONMENTS Option Section(s) Description Federal Impact(s) Number of
ANSI of Option Government X9.17 Use 21 8.3 Use Forbidden Provides 8.4 " CRLF" interoperability
8.5 as a field delimiter 22 Table I Logging of Mandatory Prudent accounting CSMs and control
practice 23 8.1 Use of Optional Reduces cost; centers improves security (CKD and CKT) TABLE II
SUMMARY OF OPTIONS AND SELECTIONS: POINT_TO_POINT ENVIRONMENT Option
Section(s) Description Federal Impact(s) Number of ANSI of Option Government X9.17 Use 9 8.6.2
Key Use of *KK Reduces cost; 8.6.4 encrypting is mandatory improves security key length 10 Table II
Notariza- Mandatory Provides a digital tion of signature keys capability; improves security 11 8.6.2
Sending Optional Operational Table III key flexibility encrypting keys in KSMs 12 4.3 Send Optional
Implementation 8.6.2 either one allows encryption 8.6.3 or two and authentication 8.6.4 data keys keys
to be sent in the same message TABLE III SUMMARY OF OPTIONS AND SELECTIONS: KEY
DISTRIBUTION CENTER ENVIRONMENT Option Section(s) Description Federal Impact(s)
Number of ANSI of Option Government X9.17 Use 12 4.3 Send Optional Implementation 8.6.2 either
one allows encryption 8.6.3 or two and authentication 8.6.4 data keys keys to be sent in the same
message 24 8.2 RSIs from Optional Automated method of 8.6.3 Party A to acquiring keys a CKD 25
8.6.3 Unsolicited Optional Reduces RTR messages communication costs; allows centralized control 27
7.3.3 Use of a Window Reduces costs; count technique provides window of Appendix interoperability
F of ANSI X9.17 is mandatory TABLE IV SUMMARY OF OPTIONS AND SELECTIONS: KEY
TRANSLATION CENTER ENVIRONMENT Option Section(s) Description Federal Impact(s)
Number of ANSI of Option Government X9.17 Use 9 8.6.2 Key Use of *KK Reduces costs; 8.6.4
encrypting is mandatory improves security key length 26 8.6.4 Send KDs Mandatory Reduces costs
and or (*)KKs that *KKs load on the CKT to a CKT be sent for translation 27 7.3.3 Use of a Window
Reduces costs; count technique provides window of Appendix interoperability F of ANSI X9.17 is
mandatory
APPENDIX A ANSI X9.17 INTERPRETATIONS
Ambiguities and inconsistencies have been noted in ANSI X9.17 during the implementation of the
standard. The following items contain interpretations of the standard which have been made. The
requirements for Federal Government use appear in underlined bold face type. A.1 SENDING AN
ESM IN RESPONSE TO AN RSM SENT IN RESPONSE TO A DSM. Problem: The standard
explicitly states that "when an RSM [sent in response to a DSM] is received in error, no ESM shall be
sent, and manual recovery procedures are required". In addition, the figures which depict message flow
with errors do not show an ESM in response to an RSM to a DSM However, the description in the
processing of an RSM contradicts this and implies that an ESM to an RSM to a DSM is required. In
particular, it states that "If an IDD field is present, this RSM is in response to a DSM ... If the IDD does
not match one of the IDD fields sent in the DSM to which this RSM responds, this shall cause
processing of the RSM to cease and the generation and transmission to the originating party of an ESM
with an "I" in the ERF field. I.e., ERF/I." Interpretation The first statement is considered to be the
appropriate action, i.e., an ESM shall not be sent in response to an RSM which responds to a DSM. An
error found in the RSM to a DSM should cause processing of the RSM to cease, and manual recovery
procedures should be used to resolve the discrepancy. A.2 THE USE OF NAMED AND UNNAMED
KEYS Problem: The standard specifies that a key may be unnamed if it is the only key of that type
shared between two parties or between a party and a center . The standard does not forbid naming a
key even if it is the only key of that type shared. The combination of these two facts implies that if one
and only one key of a particular type is shared, then that key may or may not be named; and that if
more than one key of a particular type is shared, then all such keys must be named. In addition, there
are numerous statements in the standard which specify that the key name need not be used in key
identifier subfields if it is the only key of that type shared. The following difficulties arise: o What is
the appropriate action when several keys of a particular type are shared (and hence named), and a KSM
is received containing a single unnamed key of the same type? o How should a party respond when a
single key of a particular type is shared, the key is unnamed, and a KSM is received containing a
named key of the same type? o If a key of a particular type has a name, but it is the only one shared,
should the name be used in the key identity subfields of a KSM or in the IDD or IDA fields of DSMs,
and RSMs which respond to DSMs? o When the standard discusses actions which may be taken if the
key is the only key of that type shared, does this mean that the key is the only key of that type that may
ever be shared (e.g., there is storage for only one key of that type), or does it mean that there is only
one key of that type that is currently shared (i.e., more keys may have been shared previously or may
be shared in the future)? Interpretation: The parties to a key exchange must have a prior bi-lateral
agreement to name keys or not to name them. Once such an agreement is made, a change from naming
to not naming (or the converse) cannot be made without changing the underlying agreement
concerning the keying relationship. If key(s) are received in violation of this agreement, an ESM
should be returned with a "C" (cannot process) in the ERF field. In particular, if two parties share one
or more named keys and an unnamed key is received, the recipient shall return an ESM with a "C" in
the ERF field. If two parties share one unnamed key and a named key is received, the recipient should
return an ESM with a "C" in the ERF field. In addition, when keys are named, the names should
always be used. Refer to Option 6. A.3 DISCONTINUING VERSUS REPLACING KEYS. Problem:
The standard states that "when a (*)KK is discontinued, all keys sent encrypted under that (*)KK shall
also be discontinued without being named in the DSM". This may be implemented by maintaining a
linkage between the higher level (*)KK and the (*)KKs and KDs encrypted by it. However, when a
manually or automatically distributed (*)KK is replaced by a new (*)KK of the same name, it is not
clear whether or not all other (*)KK's and KD's distributed (encrypted) by the original (*)KK should be
discontinued. Interpretation: When a (*)KK is replaced (as opposed to discontinued) then only that
(*)KK shall be affected, and other keys which may have been encrypted by that (*)KK should not be
affected. A "linkage" shall be made between the new (*)KK and the keys encrypted by the replaced
(*)KK, so that if a compromise of the replaced (*)KK is later discovered, all keys encrypted by the
replaced (*)KK can easily be identified and discontinued. A.4 ARCHIVING OF KEYS Problem:
Section 3.6.3 discusses the archiving of keys, but does not state that archiving MUST be done or
suggest when it should be done. However, it is a good business practice to archive a discontinued key
if the key may be needed later. Should replaced keys also be archived? Interpretation: Replacing a key
by a new key with the same name effectively discontinues the original key, and the key should,
therefore, be archived. The archiving of keys in any system is regarded as good accounting practice.
The transactions may have to be reconstructed at a later date to verify that the correct action was taken.
A.5 DELAYS BETWEEN THE SENDING OF AN RSM TO A KSM AND THE RECEIPT OF A
RESPONSE Problem: If an RSM is sent in response to a KSM, either an ESM response is expected or
no response is expected. The standard does not address the time interval to wait until it is known that
the RSM was received successfully. Interpretation: This is outside the scope of ANSI X9.17. However,
this problem does not occur if, upon correct receipt of the RSM, the sender of the KSM immediately
sends valid data protected using the data keys sent in the KSM. Receipt of that data and its subsequent
successful authentication or decryption provides a positive acknowledgement that the RSM was
received correctly. A.6 CONFUSION ABOUT THE UNIQUE IDENTIFICATION OF DATA KEYS
Problem: The standard never explicitly states how keys are to be uniquely identified. At first, it appears
that keys can be uniquely identified by their sharing party, key identifier, and key type ((*)KK or KD).
However, the standard explicitly states that "Two data keys with the same name may be sent in the
same message". Unless otherwise determined by prior agreement, if two KDs are sent in the same
message, the first KD shall be used by the ultimate recipient for authentication; the second shall be
used for encryption". Therefore, KDs may be identified not only by the sharing party, key identifier,
and type (KD), but also by a subtype (authentication or encryption). Interpretation (*)KKs may be
uniquely identified by their sharing party, key identifier and their type (i.e., key encrypting key). KDs
may be identified by their sharing party, key identity, their type (data key) and their subtype (data key
for authentication or data key for encryption). A.7 KD REPLACEMENT CONFUSION Problem:
When two data keys are sent in the same message, the first is designated as an authentication key; the
second as an encryption key. If a KSM is received with two KDs having distinct identifiers, the first
KD (say, KDX) is an authentication key, and the second KD (say, KDY) is an encryption key. If
another KSM is received using the same two distinct KD identifiers, but the key with identifier KDY is
first and the key with identifier KDX is second, it is unclear whether the new KDY (an authentication
key) replaces the old KDY (an encryption key), or if this situation is illegal. The same goes for the
replacement of the old KDX (an authentication key) by the new KDX (an encryption key).
Interpretation: The new KDY (an authentication key) replaces the old KDY (an encryption key), and
the new KDX (an encryption key) replaces the old KDX (an authentication key). Section 6.4 states that
"all stored keys of the same type (key encrypting keys or data keys) with the same name shall be
replaced". A.8 IMPLICIT DESIGNATION OF THE USE OF A DATA KEY FOR
AUTHENTICATION OR ENCRYPTION. Problem: The standard states that "A data key can be used
for either encryption or authentication but not both, except for a Cryptographic Service Message". This
is interpreted to mean that this stipulation applies to the entire cryptoperiod of the key, not just for a
single message. I.e., once a key is used for authentication of one message, it can never be used as an
encryption key, and conversely, once a key is used as an encryption key, it can never be used as an
authentication key. The standard does not designate the purpose of a single KD field in a message.
However, if an IV accompanies that KD, the KD could be considered to be an encryption key. If the
single KD is not accompanied by an IV, the designation as an authentication or encryption key is not
known. Interpretation: When one KD is sent in a message, the first use of that KD after it is sent in a
CSM shall determine its use for the remainder of the key's cryptoperiod unless a bilateral agreement
states otherwise. A.9 TERMINATION OF A KEYING RELATIONSHIP UPON THE RECEIPT OF A
DSM CONTAINING A NULL IDD FIELD Problem: The standard indicates that an empty IDD field
in a DSM means that the entire keying relationship should be terminated. However, the standard never
explicitly states what the entire relationship is. Interpretation: The keying relationship consists of all
manually and automatically distributed keys and IVs shared with the other party. The keying
relationship is terminated (i.e., all keys and IVs are deleted) if the DSM contains either a single NULL
IDD field, or several IDD fields, one or more of which are NULL. Resumption of the keying
relationship will then require a redistribution of manual keys, or, in the case of a center environment,
utilization of the center to re-establish a keying relationship. Note that in generating the RSM to the
DSM, the IDD fields must be copied from the DSM to the RSM. This is interpretated to mean that the
fields are copied in the order in which they were received in the DSM. A.10 RECEIPT OF AN RSI
WHICH REQUESTS A *KK TO BE SENT WHEN ONLY A MANUALLY DISTRIBUTED KK IS
SHARED Problem: If an RSI is received with a *KK in the SVR field, but only a single manually
distributed KK is shared, there is no error identified to return in an ESM. In fact, in Section 10.7 on
processing an RSI message, the SVR field is not even checked. Interpretation: The SVR field of an RSI
must be checked for appropriate requests, including the presence of a *KK request when only a KK is
shared, as well as a request for both a KK and a *KK. An error code of "C" shall be returned in the
ERF field of an ESM when an error of this type is detected. A.11 PROCESSING A MISROUTED
CSM Problem: The standard indicates that if the party identified in the RCV field of a received CSM is
not the party processing the CSM, then the message has been misrouted and shall not be processed
further. The standard does not discuss the handling of this misrouted CSM. Interpretation: If the
originator of the CSM is known, the party processing the CSM may notify the originator by manual
means, since no error code is specifically indicated for this type of error, or an ESM may be returned
with the general purpose error code "C", or the receiver could ignore the received message and send no
response. If the originator of the CSM is not known (e.g., in the context of the cryptographic system
data base, the communications network, or another relationship), the CSM should be disregarded. A.12
USING AN IV ONLY WITH THE KD WITH WHICH IT WAS SENT Problem: When an IV is sent in
a CSM, it is encrypted by the last (or only) KD in the message. No restriction is made concerning its
use in the encryption of data messages. Specifically, the standard does not indicate whether or not the
IV may be used with KDs other than the one which encrypted it in the CSM. Interpretation: The IV is
intended to be used with the KD which encrypted it in the CSM. However, this is outside the scope of
ANSI X9.17. A.13 PRESENCE OF THE IDK2 SUBFIELD IN THE KD FIELD OF A KSM Problem:
When a (*)KK field is present in a KSM, the KD(s) present in that KSM is encrypted by that (*)KK.
The IDK2 subfield is not really necessary in the KD field because the key encrypting key is known.
However, there is also a statement that "If an IDK2 subfield is not present, the (*)KK used to decrypt
the (*)KK [replace with KD] is the only one shared by the message originator and recipient". This is
confusing when a manually distributed (*)KK is shared, since if there is a (*)KK in the message, there
are at least two (*)KKs to choose from, the (*)KK in the message and the manually distributed one.
Interpretation: If a (*)KK is present in the KSM, use that (*)KK to decrypt the KD in the field. If no
(*)KK is present in the KSM, but the IDK2 subfield is present in the KD field(s), use the (*)KK named
in the IDK2 subfield to decrypt the KD(s). If no (*)KK is present in the message and no (*)KK is
named in the IDK2 subfield of the KD field(s), use the only (*)KK shared by the parties identified in
the ORG and RCV fields. If more than one (*)KK is shared, send an ESM with a "C" (Cannot process)
code in the ERF field. A.14 PROTECTION OF THE HEADER, MAC FIELD TAG AND THE
CLOSING PARENTHESIS IN A CSM Problem: In the CSMs which are authenticated using a MAC
(e.g., KSM, DSM, RSM), the MAC is computed on the message from the "M" in the message class
field tag ("MCL") through the space prior to the "M" in the MAC field tag ("MAC"). Since the CSM
header ("CSM("), the MAC field tag ("MAC") and the closing parenthesis are outside the authenticated
text, these characters could be modified without altering the MAC. Interpretation: This is true. Errors in
these areas need to be checked by the program itself or by the communications routines. If the errors
are not detected by the communications routines, the message could be disregarded. A.15 VALUE OF
THE CTP FIELD IN AN ESM WHEN THE IDENTITY OF THE (*)KK USED TO PROTECT A
KSM IS NOT KNOWN Problem: In the Point-to-Point environment, an ESM which responds to a
KSM requires a CTP field containing the expected count. However, there is at least one situation where
it is necessary to send an ESM in response to a KSM when the expected count is not known. This
situation occurs when the ESM is being sent because the manual (*)KK identified by the IDK2
subfield of the (*)KK field (or the KD field if the (*)KK field is not present) is not known and hence its
associated receive count (the expected count) is not known. Solution: Since the count is not known, the
count field returned in the ESM shall be a null field (i.e., CTP/ with nothing after the solidus (slash)).
A.16 IDA FIELD IN A DSM Problem: The standard does not permit a data encryption key to be used
for data authentication and vice versa. However,a data encryption key is sometimes used in the
authentication process for CSMs (i.e., ERSs, RFSs, RTRs, KSMs and RSMs). This occurs in two
cases: (1) when two KDs are sent in the same message and (2), when only one KD is sent which may
be an encryption key. In the first case, the KDs are combined to produce the authentication key, and in
the second case, the KD in the message is used. The KD identified in the IDA field of a DSM is used to
authenticate the DSM and the RSM which responds to the DSM. The standard does not specify
whether the KD identified in the IDA field should be an authentication key or an encryption key.
Interpretation: Since encryption keys are used for the authentication of other CSMs, the KD identified
in the IDA field may be either an authentication KD or an encryption KD. In fact, if a communicating
pair share only an encryption key, there is no authentication key with which to authenticate a DSM.
However, when possible, an authentication key rather than an encryption key shall be identified in the
IDA field and used to authenticate the DSM. A.17 MESSAGE AND EVENT LOGGING Problem: The
standard states that logging is mandatory when the received count in CSMs is not equal to the expected
count. Logging is optional when the received and expected counts are equal. The implication is that the
log contains something about the event, but the standard does not specify what should be included in
the log. Solution: The most appropriate information to log would be the CSM itself, the expected count
and the time of receipt as a minimum. It would indeed be desirable to log all CSMs, and the Federal
Government is in fact required to do so (see Option 22). A.18 PROCESSING AN EDK FIELD
Problem: The inclusion of an EDK field in a KSM or RTR is optional. However, if an EDK field is
present in a CSM, it is not clear whether the receiver who does not generate an EDK field is required to
process the message and field anyway (i.e., may ignore the field), or may return an "Option Not
Implemented" error code ("O") in an ESM, if appropriate. Interpretation: Since there is no identified
method for checking the contents of the EDK field, a party who doesn't send the EDK field may not
know how to check a received EDK for acceptability. Ignoring the field would not be in accordance
with the originator's request. Therefore it would be preferable that the receiving party return an ESM
with a "Cannot Process" or an "Option not implemented" error code in this case. A.19 TWO AND
THREE LAYER ARCHITECTURES Problem: The standard permits two or three layers of keys in its
architecture. However, there are several conflicting statements regarding the use of these two
architectures. o "The architecture shall consist of either two or three layers of keys." This seems to say
that the two architectures shouldn't co-exist in the same implementation. o "All implementations shall
have the capability of functioning in a two layer architecture." This seems to say that an
implementation with a three layer architecture should also be able to switch to a two layer "mode". o
"In a three layer architecture,...When no key encrypting key is transmitted, one or two data keys shall
be sent and shall be encrypted under an automatically distributed key encrypting key which has been
previously exchanged between the communicating pair." This seems to say that you can't use a
manually distributed key encrypting key to encrypt a data key when a three layer architecture is
implemented, i.e., you can't switch to a two layer architecture. Interpretation: An implementation may
use the manually distributed (*)KKs to encrypt keys to be exchanged irregardless of whether a two or
three layer architecture has been implemented. However, if a (*)KK is exchanged, only a manually
distributed (*)KK may be used to encrypt that key.
APPENDIX B ABBREVIATIONS USED IN THIS DOCUMENT
Abbreviation Meaning ANSI American National Standards Institute ATM Automatic Teller Machine
CBC Cipher Block Chaining CRLF Space, Carriage Return, Line Feed CKD Key Distribution Center
CKT Key Translation Center COMSEC Communications Security CR Carriage Return CRLF Carriage
Return and Line Feed CSL Computer Systems Laboratory CSM Cryptographic Service Message CTA
Count "A" CTB Count "B" CTP Count "P" DES Data Encryption Standard DSM Disconnect Service
Message EDC Error Detection Code EDK Effective Date of Key ERF Error Field ERS Error Recovery
Service Message ESM Error Service Message FIPS PUBS Federal Information Processing Standards
Publications IDA Identity of Key for Authentication IDC Identity of Key Distribution Center or Key
Translation Center IDD Identity of key to be discontinued IDU Identity of Ultimate Recipient IDK1
Key Identifier (subfield) IDK2 Key Encrypting Key Identifier (subfield) IV Initialization Vector KD
Data Key KDU Notarized Data Key for the Ultimate Recipient KK Key Encrypting Key *KK Key
Encrypting Key Pair (*)KK Key Encrypting Key or Key Encrypting Key Pair *KKU Notarized Key
Encrypting Key Pair for the Ultimate Recipient (*)KKU Notarized Key Encrypting Key or Key
Encrypting Key Pair for the Ultimate Recipient KSM Key Service Message LF Line Feed MAC
Message Authentication Code NIST National Institute of Standards and Technology ORG Originator
identity PTP Point-to-Point (environment) RCV Receiver (Recipient) identity RFS Request for Service
Message RSI Request Service Initiation Message RSM Response Service Message RTR Response to
Request Message SVR Service Request Message FIPS PUB 180, 1993 MAY 11 FIPS PUB 180, 1993
MAY 11 FIPS PUB 180
Federal Information Processing Standards Publication 180
1993 May 11 U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology
SECURE HASH STANDARD
/*** NOTE: NOT OFFICIAL. HARD COPY IS THE OFFICIAL VERSION. ^ is used for
exponentiation or superscript. ***/ CATEGORY: COMPUTER SECURITY U.S. DEPARTMENT OF
COMMERCE, Barbara Franklin, Secretary NATIONAL INSTITUTE OF STANDARDS AND
TECHNOLOGY
Foreword
The Federal Information Processing Standards Publication Series of the National Institute of Standards
and Technology (NIST) is the official series of publications relating to standards and guidelines
adopted and promulgated under the provisions of Section 111(d) of the Federal Property and
Administrative Services Act of 1949 as amended by the Computer Security Act of 1987, Public Law
100-235. These mandates have given the Secretary of Commerce and NIST important responsibilities
for improving the utilization and management of computer and related telecommunications systems in
the Federal Government. The NIST, through the Computer Systems Laboratory, provides leadership,
technical guidance, and coordination of Government efforts in the development of standards and
guidelines in these areas. Comments concerning Federal Information Processing Standards
Publications are welcomed and should be addressed to the Director, Computer Systems Laboratory,
National Institute of Standards and Technology, Gaithersburg, MD 20899. James H. Burrows, Director
Computer Systems Laboratory
Abstract
This standard specifies a Secure Hash Algorithm (SHA) which can be used to generate a condensed
representation of a message called a message digest. The SHA is required for use with the Digital
Signature Algorithm (DSA) as specified in the Digital Signature Standard (DSS) and whenever a
secure hash algorithm is required for federal applications. The SHA is used by both the transmitter and
intended receiver of a message in computing and verifying a digital signature. Key words: Computer
security, digital signatures, Federal Information Processing Standard, hash algorithm. FIPS PUB 180
Federal Information Processing Standards Publication 180 1993 MAY 11
ANNOUNCING THE SECURE HASH STANDARD
Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National
Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant to
Section 111(d) of the Federal Property and Administrative Services Act of 1949 as amended by the
Computer Security Act of 1987, Public Law 100-235. Name of Standard: Secure Hash Standard.
Category of Standard: Computer Security. Explanation: This Standard specifies a Secure Hash
Algorithm (SHA) for computing a condensed representation of a message or a data file. When a
message of any length < 2^64 bits is input, the SHA produces a 160-bit output called a message digest.
The message digest can then be input to the Digital Signature Algorithm (DSA) which generates or
verifies the signature for the message (see Figure 1). Signing the message digest rather than the
message often improves the efficiency of the process because the message digest is usually much
smaller in size than the message. The same hash algorithm must be used by the verifier of a digital
signature as was used by the creator of the digital signature. The SHA is called secure because it is
computationally infeasible to find a message which corresponds to a given message digest, or to find
two different messages which produce the same message digest. Any change to a message in transit
will, with very high probability, result in a different message digest, and the signature will fail to
verify. The SHA is based on principles similar to those used by Professor Ronald L. Rivest of MIT
when designing the MD4 message digest algorithm ("The MD4 Message Digest Algorithm," Advances
in Cryptology - CRYPTO '90 Proceedings, Springer-Verlag, 1991, pp. 303-311), and is closely
modelled after that algorithm. Approving Authority: Secretary of Commerce. Maintenance Agency:
U.S. Department of Commerce, National Institute of Standards and Technology, Computer Systems
Laboratory. Applicability: This standard is applicable to all Federal departments and agencies for the
protection of unclassified information that is not subject to section 2315 of Title 10, United States
Code, or section 3502(2) of Title 44, United States Code. This standard is required for use with the
Digital Signature Algorithm (DSA) as specified in the Digital Signature Standard (DSS) and whenever
a secure hash algorithm is required for federal applications. Private and commercial organizations are
encouraged to adopt and use this standard. Applications: The SHA may be used with the DSA in
electronic mail, electronic funds transfer, software distribution, data storage, and other applications
which require data integrity assurance and data origin authentication. The SHA may also be used
whenever it is necessary to generate a condensed version of a message. Implementations: The SHA
may be implemented in software, firmware, hardware, or any combination thereof. Only
implementations of the SHA that are validated by NIST will be considered as complying with this
standard. Information about the requirements for validating implementations of this standard can be
obtained from the National Institute of Standards and Technology, Computer Systems Laboratory,
Attn: SHS Validation, Gaithersburg, MD 20899. Export Control: Implementations of this standard are
subject to Federal Government export controls as specified in Title 15, Code of Federal Regulations,
Parts 768 through 799. Exporters are advised to contact the Department of Commerce, Bureau of
Export Administration for more information. Patents: Implementations of the SHA in this standard
may be covered by U.S. and foreign patents. Implementation Schedule: This standard becomes
effective October 15, 1993. Specifications: Federal Information Processing Standard (FIPS 180) Secure
Hash Standard (affixed). Cross Index: a. FIPS PUB 46-1, Data Encryption Standard. b. FIPS PUB 73,
Guidelines for Security of Computer Applications. c. FIPS PUB 140-1, Security Requirements for
Cryptographic Modules. d. FIPS PUB XX, Digital Signature Standard. Qualifications: While it is the
intent of this standard to specify a secure hash algorithm, conformance to this standard does not assure
that a particular implementation is secure. The responsible authority in each agency or department shall
assure that an overall implementation provides an acceptable level of security. This standard will be
reviewed every five years in order to assess its adequacy. Waiver Procedure: Under certain exceptional
circumstances, the heads of Federal departments and agencies may approve waivers to Federal
Information Processing Standards (FIPS). The head of such agency may redelegate such authority only
to a senior official designated pursuant to section 3506(b) of Title 44, United States Code. Waiver shall
be granted only when: a. Compliance with a standard would adversely affect the accomplishment of
the mission of an operator of a Federal computer system; or b. Compliance with a standard would
cause a major adverse financial impact on the operator which is not offset by Government-wide
savings. Agency heads may act upon a written waiver request containing the information detailed
above. Agency heads may also act without a written waiver request when they determine that
conditions for meeting the standard cannot be met. Agency heads may approve waivers only by a
written decision which explains the basis on which the agency head made the required finding(s). A
copy of each decision, with procurement sensitive or classified portions clearly identified, shall be sent
to: National Institute of Standards and Technology; ATTN: FIPS Waiver Decisions, Technology
Building, Room B-154, Gaithersburg, MD 20899. In addition, notice of each waiver granted and each
delegation of authority to approve waivers shall be sent promptly to the Committee on Government
Operations of the House of Representatives and the Committee on Government Affairs of the Senate
and shall be published promptly in the Federal Register. When the determination on a waiver applies to
the procurement of equipment and/or services, a notice of the waiver determination must be published
in the Commerce Business Daily as a part of the notice of solicitation for offers of an acquisition or, if
the waiver determination is made after that notice is published, by amendment to such notice. A copy
of the waiver, any supporting documents, the document approving the waiver and any accompanying
documents, with such deletions as the agency is authorized and decides to make under 5 United States
Code Section 552(b), shall be part of the procurement documentation and retained by the agency.
Where to Obtain Copies of the Standard: Copies of this publication are for sale by the National
Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. When
ordering, refer to Federal Information Processing Standards Publication 180 (FIPS PUB 180), and
identify the title. When microfiche is desired, this should be specified. Prices are published by NTIS in
current catalogs and other issuances. Payment may be made by check, money order, deposit account or
charged to a credit card accepted by NTIS. FIPS PUB 181, 1993 OCTOBER 5 FIPS PUB 181, 1993
OCTOBER 5
Federal Information Processing Standards Publication 181
1993 October 5
Announcing the Standard for Automated Password Generator
Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National
Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant to
Section 111(d) of the Federal Property and Administrative Services Act of 1949 as amended by the
Computer Security Act of 1987, Public Law 100-235. 1. Name of Standard. Automated Password
Generator. 2. Category of Standard. Computer Security. 3. Explanation. A password is a protected
character string used to authenticate the identity of a computer system user or to authorize access to
system resources. When users are allowed to select their own passwords they often select passwords
that are easily compromised. An automated password generator creates random passwords that have no
association with a particular user. This Automated Password Generator Standard specifies an algorithm
to generate passwords for the protection of computer resources. This standard is for use in conjunction
with FIPS PUB 112, Password Usage Standard, which provides basic security criteria for the design,
implementation, and use of passwords. The algorithm uses random numbers to select the characters
that form the random pronounceable passwords. The random numbers are generated by a random
number subroutine based on the Electronic Codebook mode of the Data Encryption Standard (DES)
(FIPS PUB 46-1). The random number subroutine uses a pseudorandom DES key generated in
accordance with the procedure described in Appendix C of ANSI X9.17. Similar to DES, the FIPS for
Automated Password Generator is an interoperability standard. Interoperability standards specify
functions and formats so that data transmitted can be properly acted upon when received by another
computer. This type of standard is independent of physical implementation. Implementors are required
to use the algorithm defined in the FIPS, however, they are not constrained in how they package it. For
discussion purposes a NIST implementation of the Automated Password Generator is provided. It is
expected that commercial implementations will be based on the latest technologies and differ from
NIST's, however the results should be logically equivalent to that of this FIPS. 4. Approving Authority.
Secretary of Commerce. 5. Maintenance Agency. U.S. Department of Commerce, National Institute of
Standards and Technology (NIST), Computer Systems Laboratory (CSL). 6. Cross Index. a. American
National Standards Institute (ANSI) X9.28, Financial Institution Multiple Center Key Management
(Wholesale) Draft. b. Department of Defense CSC-STD-002-85, Password Management Guideline. c.
Federal Information Processing Standards Publication (FIPS PUB) 48, Guidelines on Evaluation of
Techniques for Automated Personal Identification. d. Federal Information Processing Standards
Publication (FIPS PUB) 46-1, Data Encryption Standard. e. Federal Information Processing Standards
Publication (FIPS PUB) 81, DES Modes of Operation. f. Federal Information Processing Standards
Publication (FIPS PUB) 83, Guideline on User Authentication Techniques for Computer Network
Access Control. g. Federal Information Processing Standards Publication (FIPS PUB) 112, Password
Usage. h. Federal Information Processing Standards Publication (FIPS PUB) 171, Key Management
Using ANSI X9.17. i. National Technical Information Service (NTIS) AD A 017676, A Random Word
Generator for Pronounceable Passwords. 7. Objectives. The objectives of this standard are to: a.
improve the administration of password systems that are used for authenticating the identity of
individuals accessing computer resources or files; b. provide a standard automated method for
producing pronounceable passwords that have no association with a particular user; c. produce
passwords that are easily remembered, stored, and entered into computer systems, yet not readily
susceptible to automated techniques that have been developed to search for and disclose passwords. 8.
Applicability. This standard is applicable to the development of procurement or design specifications
for implementing an automatic password generation algorithm within a computer system. It shall be
used by all Federal departments and agencies when there is a requirement for computer generated
pronounceable passwords for authenticating users of computer systems, or for authorizing access to
resources in those systems. This standard does not require the use of passwords in a computer system,
but establishes an automatic password generation algorithm for use in systems where an agency's
computer security policy requires computer generated pronounceable passwords. It should be used in
conjunction with FIPS PUB 112, Password Usage Standard, which specifies basic security criteria for
the design, implementation, and use of passwords. 9. Export Control. The Bureau of Export
Administration, U.S. Department of Commerce, is responsible for administering export controls on
cryptographic products used for authentication and access control, which categories would include
implementations of the Automated Password Generator. Vendors should contact the following for a
product classification: Bureau of Export Administration U.S. Department of Commerce P.O. Box 273
Washington, DC 20044 Telephone: (202) 482-0708 Following this determination, the vendor will be
informed whether an export license is required and will be provided further information as appropriate.
10. Specifications. Federal Information Processing Standard (FIPS) 181, Automated Password
Generator (affixed); 11. Qualifications. The Automated Password Generator uses the Electronic
Codebook (ECB) mode of the Data Encryption Standard (DES), Federal Information Processing
Standard 46-1 (FIPS PUB 46- 1), as the random number generator. This mode of operation is specified
in FIPS 81, DES Modes of Operation. The protection provided by the DES algorithm against potential
threats has been reviewed every 5 years since its adoption in 1977 and has been reaffirmed during each
of those reviews. The DES, and the possible threats reducing the security provided by the use of DES,
will undergo continual review by NIST and other cognizant Federal organizations. The new technology
available at review time will be evaluated to determine its impact on the DES. In addition, the
awareness of any breakthrough in technology or any mathematical weakness of the algorithm will
cause NIST to reevaluate the DES and provide necessary revisions. 12. Implementation Schedule. This
Standard becomes effective March 25, 1994. 13. Waivers. Under certain exceptional circumstances, the
heads of Federal departments and agencies may approve waivers to Federal Information Processing
Standards (FIPS). The head of such agency may redelegate such authority only to a senior official
designated pursuant to section 3506(b) of Title 44, U.S. Code. Waivers shall be granted only when
compliance with a standard would: a. adversely affect the accomplishment of the mission of an
operator of a Federal computer system, or b. cause a major adverse financial impact on the operator
which is not offset by Government-wide savings. Agency heads may act upon a written waiver request
containing the information detailed above. Agency heads may also act without a written waiver request
when they determine that conditions for meeting the standard cannot be met. Agency heads may
approve waivers only by a written decision which explains the basis on which the agency head made
the required finding(s). A copy of each such decision, with procurement sensitive or classified portions
clearly identified, shall be sent to: National Institute of Standards and Technology; ATTN: FIPS
Waiver Decisions; Technology Building, Room B-154; Gaithersburg, MD 20899. In addition, notice
of each waiver granted and each delegation of authority to approve waivers shall be sent promptly to
the Committee on Government Operations of the House of Representatives and the Committee on
Government Affairs of the Senate and shall be published promptly in the Federal Register. When the
determination on a waiver applies to the procurement of equipment and/or services, a notice of the
waiver determination must be published in the Commerce Business Daily as a part of the notice of
solicitation for offers of an acquisition or, if the waiver determination is made after that notice is
published, by amendment to such notice. A copy of the waiver, any supporting documents, the
document approving the waiver, and any supporting and accompanying documents, with such
deletions as the agency is authorized and decides to make under 5 U.S.C Sec. 552(b), shall be part of
the procurement documentation and retained by the agency. 14. Where to Obtain Copies. Copies of
this publication are available for sale by the National Technical Information Service, U.S. Department
of Commerce, Springfield, VA 22161. When ordering, refer to Federal Information Processing
Standards Publication 181 (FIPSPUB181), and identify the title. When microfiche is desired, this
should be specified. Payment may be made by check, money order, credit card, or deposit account.
Federal Information Processing Standards Publication 181 1993 October 5 Announcing the Standard
for Automated Password Generator
Contents
1.0 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . .6 2.0 TECHNICAL EXPLANATION . . . . . . . . . . .
. . . . . . 6 2.1 Unit Table . . . . . . . . . . . . . . . . . . 6 2.2 Digram Table . . . . . . . . . . . . . . . . . 7 2.3 Random
Number Generator Subroutine . . . . . . 7 2.4 Random Word Algorithm. . . . . . . . . . . . . 8 2.5 NIST
Implementation. . . . . . . . . . . . . . 9 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.0 INTRODUCTION
The Automated Password Generator standard is derived from a C-code version of the program
described in "A Random Word Generator For Pronounceable Passwords," National Technical
Information Service (NTIS) AD A 017676. The original program used Unix system functions to
produce the random numbers needed by the password generator. These functions were replaced with a
DES-based random number subroutine that uses DES in the Electronic Code Book (ECB) mode. As
input, DES uses the old password or user supplied character string, and a pseudorandom key created in
accordance with the procedure described in Appendix C of ANSI X9.17. Any change to either the key
or input data string causes DES to generate an entirely different random number. Every time this
occurs the password generator creates a new random password.
2.0 TECHNICAL EXPLANATION
The Automated Password Generator standard is organized as a main procedure that references three
major components: (1) the "unit table"; (2) the "digram table"; and (3) the "random number
subroutine." The random password generator works by forming pronounceable syllables and
concatenating them to form a word. Rules of pronounceability are stored in a table for every unit and
every pair of units (digram). The rules are used to determine whether a given unit is legal or illegal,
based on its position within the syllable and adjacent units. Most rules and checks are syllable oriented
and do not depend on anything outside the current syllable. The main procedure (algorithm) defines the
internal rules used to generate random words. The three components and the algorithm are described
below. Appendix A is the code for the NIST implementation of the Automated Password Generator
standard. This code consists of the C-code version of the program described in "A Random Word
Generator For Pronounceable Passwords," the code that comprises the DES random number
subroutine, the actual DES subroutine, and the code for generating the pseudorandom key.
Implementations in other programming languages are acceptable, however, the results obtained must
be logically equivalent to those produced by this standard. In the NIST implementation of the
password generator, the values selected for the two DES keys and the seed for the random number
generator are readable in the code (Appendix A). In an actual vendor or user developed implementation
the values of the keys and the seed would be secret, randomly generated values set by the application.
2.1 Unit Table The unit table defines the units (alphabetic characters) and specifies rules pertaining to
the individual units used in a randomly generated word. For example, the location of vowels in the
words generated is determined by these rules. The unit table used in the Automated Password
Generator standard is identical to that furnished in the report "A Random Word Generator For
Pronounceable Passwords" (item i in Cross Index). 2.2 Digram Table The digram table specifies rules
about all possible pairs of units and the juxtaposition of units. The table contains one entry for every
pair of units (digram), whether that pair is allowed or not. The random word generator ensures that the
rules specified in the digram table are satisfied for every two consecutive units in the word being
formed. The digram table is also from the original report. 2.3 Random Number Generator Subroutine
The random number generator uses a DES subroutine to produce double precision floating point values
between 0 and (excluding) 1. These numbers are multiplied by a program variable n which is an integer
value. This operation yields a random integer between 0 and (n-1) inclusive. The random numbers
created by the DES routine serve as input to the random word generator. The subroutine to generate
these numbers is called by the word generator each time a character (unit) is needed. Not all characters
generated will be acceptable to the word generator in every position of the word. Each character is
checked for appropriateness using the rules defined by the unit and digram tables. Therefore the
random number generator subroutine will be repeatedly called until an acceptable character is returned.
An upper limit of 100 calls is placed on generating any particular character. If that number is reached
the whole word is discarded and the program starts over. The actual distribution of legal units is
different for every position in a particular word which, for any unit, depends on the units that precede it
as well as the units and digram tables. The random number subroutine itself makes no tests for legal
units. As its input DES accepts two 64 bit data blocks. One consists of the old password or a data
string; the other is a 64 bit (56 bits + 8 parity bits) pseudorandom key derived using the procedure
described in Appendix C of ANSI X9.17. The old password is entered manually from the keyboard. An
input array is created from the first eight bytes of the password or input string. The program will accept
a null string (carriage return). All characters past the eighth are disregarded. If the input block is less
than eight characters long the extra elements in the input array are filled with ASCII 0. The Electronic
Codebook (ECB) mode of DES described in FIPS 81 ("DES Modes of Operation," December 2, 1980)
is then used to encrypt the input data. The output is a 64-bit random number which is the encrypted
form of the input. The first function in the DES structure is setkey(), which converts the pseudorandom
key to a format used by DES for the encryption. The command-line options sent to setkey are (0, 0,
key). The first 0 is set so that setkey() does not generate parity; the second 0 tells setkey() that
encryption (rather than decryption) is required. Key is a pointer to the beginning of the key array. After
setkey(), the des() function is called. For input it uses the addresses of the input and output arrays. Both
input and output are defined as unsigned character arrays of length 8 bytes. The output array, out, is
sent to a function, answer(), which returns the final required number. The function answer() takes in the
address of the output array as an unsigned char pointer and the integer n for which a value of 0 to (n-1)
is needed by the random word program. This function creates a variable sum, defined as an unsigned
integer. To obtain a numerical value from the output character array, it adds the ASCII values of the
first three elements in the out array and stores the sum in the variable sum. Thus, sum = out[0] + out[1]
+ out[2], which is an integer. To obtain a number with the required range of 0 to n-1 from sum, the
function takes the modulus of sum and n, (sum%n). This value is then returned to the calling function
within the random word program. 2.4 Random Word Algorithm The algorithm used to generate
random words is fixed and cannot be modified without changing the logic of the program. The
function of the algorithm is to determine whether a given unit, generated by the random unit
subroutine, can be appended to the end of the partial word formed so far. Rules of pronounceability are
stored in the unit and digram tables discussed above. The rules are used to check if a given unit is legal
or illegal. If illegal, the unit is discarded and the random unit subroutine is called again. Once a unit is
accepted, various state variables are updated and a unit for the next position in the word is tried. Most
rules and checks are syllable oriented and do not depend on anything outside the current syllables.
When the end of the word is reached, additional checks are made before the algorithm terminates.
Passwords created by this automated password generator are composed of the 26 characters of the
English alphabet. Although numbers and special characters are not permitted, the password space,
which is a function of the number of characters in the password, is very large. Approximately 18
million 6-character, 5.7 billion 8- character, and 1.6 trillion 10-character passwords can be created by
the program. Users should select a password space commensurate with the level of security required
for the information being protected. The password algorithm does not preclude the generation of words
found in a standard English dictionary. If required, a computerized dictionary could be used to check
for English words, and the implementation could include software tests to prevent them from being
offered to users as passwords. 2.5 NIST Implementation Figure 1 is a block diagram of the NIST
implementation of the automated password generation algorithm. Appendix A contains the C-code for
the DES, random key generation, and random word generation routines that were used in the
implementation (see shaded boxes in Fig. 1). The personal computer used by NIST to demonstrate the
standard is implementation dependent. NIST replaced the Unix random number routine in the original
version of the program with the "DES Randomizer" and "Generate Random Key" function. The DES
randomizer accepts an old password and a pseudorandom key created in accordance with Appendix C
of ANSI X9.17 ( FIPSPUB 171) and generates a random number. This number is used by the Random
Word Generator to develop a password. As the password is being generated each group of letters is
subjected to tests of grammar and semantics to determine if an acceptable word has been created. If all
tests are passed, the new password is output to the PC. In the NIST implementation, the values for
minlen and maxlen, which define the minimun and maximum size of the password, were set at 5 and 8
respectively. A user needing a fixed length password word could set these variables to a specific value.
Appendix A
This section contained a listing of the source code referenced in the Automated Password Generator
Standard. This section is not available in electronic form. Complete copies of FIPS 181, including this
appendix, may be purchased in hardcopy from the National Technical Information Service (NTIS) via
mail or telephone. National Technical Information Service U.S. Department of Commerce 5285 Port
Royal Road Springfield, VA 22161 (703) 487-4650 Order by FIPSPUB181 Price: $22.50 (Same
address and phone number for discount prices on quantity orders.) FIPS PUB 185, 1994 FEBRUARY
9 FIPS PUB 185, 1994 FEBRUARY 9
Federal Information Processing Standards Publication 185
1994 February 9 U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and
Technology
ESCROWED ENCRYPTION STANDARD
CATEGORY: TELECOMMUNICATIONS SECURITY U.S. DEPARTMENT OF COMMERCE,
Ronald H. Brown, Secretary NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY,
Arati Prabhakar, Director
Foreword
The Federal Information Processing Standards Publication Series of the National Institute of Standards
and Technology (NIST) is the official series of publications relating to standards and guidelines
adopted and promulgated under the provisions of Section 111(d) of the Federal Property and
Administrative Services Act of 1949 as amended by the Computer Security Act of 1987, Public Law
100-235. These mandates have given the Secretary of Commerce and NIST important responsibilities
for improving the utilization and management of computer and related telecommunications systems in
the Federal Government. The NIST, through the Computer Systems Laboratory, provides leadership,
technical guidance, and coordination of Government efforts in the development of standards and
guidelines in these areas. Comments concerning Federal Information Processing Standards
Publications are welcomed and should be addressed to the Director, Computer Systems Laboratory,
National Institute of Standards and Technology, Gaithersburg, MD 20899. James H. Burrows, Director
Computer Systems Laboratory
Abstract
This standard specifies an encryption/decryption algorithm and a Law Enforcement Access Field
(LEAF) creation method which may be implemented in electronic devices and used for protecting
government telecommunications when such protection is desired. The algorithm and the LEAF
creation method are classified and are referenced, but not specified, in the standard. Electronic devices
implementing this standard may be designed into cryptographic modules which are integrated into data
security products and systems for use in data security applications. The LEAF is used in a key escrow
system that provides for decryption of telecommunications when access to the telecommunications is
lawfully authorized. Key words: Cryptography, Federal Information Processing Standard, encryption,
key escrow system, security. FIPS PUB 185 Federal Information Processing Standards Publication 185
1994 February 9
Announcing the Escrowed Encryption Standard (EES)
Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National
Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant to
Section 111(d) of the Federal Property and Administrative Services Act of 1949 as amended by the
Computer Security Act of 1987, Public Law 100-235. Name of Standard: Escrowed Encryption
Standard (EES). Category of Standard: Telecommunications Security. Explanation: This Standard
specifies use of a symmetric-key encryption (and decryption) algorithm (SKIPJACK) and a Law
Enforcement Access Field (LEAF) creation method (one part of a key escrow system) which provides
for decryption of encrypted telecommunications when interception of the telecommunications is
lawfully authorized. Both the SKIPJACK algorithm and the LEAF creation method are to be
implemented in electronic devices (e.g., very large scale integration chips). The devices may be
incorporated in security equipment used to encrypt (and decrypt) sensitive unclassified
telecommunications data. Decryption of lawfully intercepted telecommunications may be achieved
through the acquisition and use of the LEAF, the decryption algorithm and the two escrowed key
components. One definition of "escrow" means that something (e.g., a document, an encryption key) is
"delivered to a third person to be given to the grantee only upon the fulfillment of a condition"
(Webster's Seventh New Collegiate Dictionary). The term, "escrow", for purposes of this standard, is
restricted to this dictionary definition. A key escrow system, for purposes of this standard, is one that
entrusts the two components comprising a cryptographic key (e.g., a device unique key) to two key
component holders (also called "escrow agents"). In accordance with the above definition of "escrow",
the key component holders provide the components of a key to a "grantee" (e.g., a law enforcement
official) only upon fulfillment of the condition that the grantee has properly demonstrated legal
authorization to conduct electronic surveillance of telecommunications which are encrypted using the
specific device whose device unique key is being requested. The key components obtained through this
process are then used by the grantee to reconstruct the device unique key and obtain the session key
which is then used to decrypt the telecommunications that are encrypted with that session key. The
SKIPJACK encryption/decryption algorithm has been approved for government applications requiring
encryption of sensitive but unclassified data telecommunications as defined herein. The specific
operations of the SKIPJACK algorithm and the LEAF creation method are classified and hence are
referenced, but not specified, in this standard. Data for purposes of this standard includes voice,
facsimile and computer information communicated in a telephone system. A telephone system for
purposes of this standard is limited to a system which is circuit switched and operating at data rates of
standard commercial modems over analog voice circuits or which uses basic-rate ISDN or a similar
grade wireless service. Data that is considered sensitive by a responsible authority should be encrypted
if it is vulnerable to unauthorized disclosure during telecommunications. A risk analysis should be
performed under the direction of a responsible authority to determine potential threats and risks. The
costs of providing encryption using this standard as well as alternative methods and their respective
costs should be projected. A responsible authority should then make a decision, based on the risk and
cost analyses, whether or not to use encryption and then whether or not to use this standard. Approving
Authority: Secretary of Commerce. Maintenance Agency: Department of Commerce, National Institute
of Standards and Technology. Applicability: This standard is applicable to all Federal departments and
agencies and their contractors under the conditions specified below. This standard may be used in
designing and implementing security products and systems, which Federal departments and agencies
use or operate or which are operated for them under contract. These products may be used when
replacing Type II and Type III (DES) encryption devices and products owned by the government and
government contractors. This standard may be used when the following conditions apply: 1. An
authorized official or manager responsible for data security or the security of a computer system
decides that encryption is required and cost justified as per OMB Circular A- 130; and 2. The data is
not classified according to Executive Order 12356, entitled "National Security Information," or to its
successor orders, or to the Atomic Energy Act of 1954, as amended. However, Federal departments or
agencies which use encryption devices for protecting data that is classified according to either of these
acts may use those devices also for protecting unclassified data in lieu of this standard. In addition, this
standard may be adopted and used by non-Federal Government organizations. Such use is encouraged
when it provides the desired security. Applications: This standard may be used in any unclassified
government and commercial communications. Use of devices conforming to this standard is voluntary
for unclassified government applications and for commercial security applications. Implementations:
The encryption/decryption algorithm and the LEAF creation method shall be implemented in electronic
devices (e.g., electronic chip packages) which are protected against unauthorized entry, modification
and reverse engineering. Implementations which are tested and validated by NIST will be considered
as complying with this standard. An electronic device shall be incorporated into a cryptographic
module in accordance with FIPS 140-1. NIST will test for conformance with FIPS 140-1. Conforming
cryptographic modules can then be integrated into security equipment for sale and use in a security
application. Information about devices that have been validated, procedures for testing equipment for
conformance with NIST standards, and information about approved security equipment are available
from the Computer Systems Laboratory, NIST, Gaithersburg, MD 20899. Export Control:
Implementations of this standard are subject to Federal Government export controls as specified in
Title 22, Code of Federal Regulations, Parts 120 through 131 (International Traffic of Arms
Regulations - ITAR). Exporters of encryption devices, equipment and technical data are advised to
contact the U.S. Department of State, Office of Defense Trade Controls for more information. Patents:
Implementations of this standard may be covered by U.S. and foreign patents. Implementation
Schedule: This standard becomes effective thirty days following publication of this FIPS PUB.
Specifications: Federal Information Processing Standard (FIPS 185), Escrowed Encryption Standard
(EES) (affixed). Cross Index: a. FIPS PUB 46-2, Data Encryption Standard. b. FIPS PUB 81, Modes of
Operation of the DES c. FIPS PUB 140-1, Security Requirements for Cryptographic Modules.
GLOSSARY:
The following terms are used as defined below for purposes of this standard: Data - Unclassified voice,
facsimile and computer information communicated over a telephone system. Decryption - Conversion
of ciphertext to plaintext through the use of a cryptographic algorithm. Device (cryptographic) - An
electronic implementation of the encryption/decryption algorithm and the LEAF creation method as
specified in this standard. Digital data - Data that have been converted to a binary representation.
Encryption - Conversion of plaintext to ciphertext through the use of a cryptographic algorithm. Key
components - The two values from which a key can be derived (e.g., KU1 ~ KU2). Key escrow - The
processes of managing (e.g., generating, storing, transferring, auditing) the two components of a
cryptographic key by two key component holders. LEAF Creation Method - A part of a key escrow
system that is implemented in a cryptographic device and creates a Law Enforcement Access Field.
Type I cryptography - A cryptographic algorithm or device approved by the National Security Agency
for protecting classified information. Type II cryptography - A cryptographic algorithm or device
approved by the National Security Agency for protecting sensitive unclassified information in systems
as specified in section 2315 of Title 10 United States Code, or section 3502(2) of Title 44, United
States Code. Type III cryptography - A cryptographic algorithm or device approved as a Federal
Information Processing Standard. Type III(E) cryptography - A Type III algorithm or device that is
approved for export from the United States. Qualifications: The protection provided by a security
product or system is dependent on several factors. The protection provided by the SKIPJACK
algorithm against key search attacks is greater than that provided by the DES algorithm (e.g., the
cryptographic key is longer). However, provisions of this standard are intended to ensure that
information encrypted through use of devices implementing this standard can be decrypted by a legally
authorized entity. Where to Obtain Copies of the Standard: Copies of this publication are for sale by
the National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161.
When ordering, refer to Federal Information Processing Standards Publication 185 (FIPS PUB 185),
and identify the title. When microfiche is desired, this should be specified. Prices are published by
NTIS in current catalogs and other issuances. Payment may be made by check, money order, deposit
account or charged to a credit card accepted by NTIS. Federal Information Processing Standards
Publication 185 1994 February 9 Specifications for the
ESCROWED ENCRYPTION STANDARD
1. INTRODUCTION
This publication specifies Escrowed Encryption Standard (EES) functions and parameters.
2. GENERAL
This standard specifies use of the SKIPJACK cryptographic algorithm and a LEAF Creation Method to
be implemented in an approved electronic device (e.g., a very large scale integration electronic chip).
The device is contained in a logical cryptographic module which is then integrated in a security
product for encrypting and decrypting telecommunications. Approved implementations may be
procured by authorized organizations for integration into security equipment. Devices must be tested
and validated by NIST for conformance to this standard. Cryptographic modules must be tested and
validated by NIST for conformance to FIPS 140-1.
3. ALGORITHM SPECIFICATIONS
The specifications of the encryption/decryption algorithm (SKIPJACK) and LEAF Creation Method 1
(LCM-1) are classified. The National Security Agency maintains these classified specifications and
approves the manufacture of devices which implement the specifications. NIST tests for conformance
of the devices implementing this standard in cryptographic modules to FIPS 140-1 and FIPS 81.
4. FUNCTIONS AND PARAMETERS
4.1 FUNCTIONS The following functions, at a minimum, shall be implemented: 1. Data Encryption:
A session key (80 bits) shall be used to encrypt plaintext information in one or more of the following
modes of operation as specified in FIPS 81: ECB, CBC, OFB (64), CFB (1, 8, 16, 32, 64). 2. Data
Decryption: The session key (80 bits) used to encrypt the data shall be used to decrypt resulting
ciphertext to obtain the data . 3. LEAF Creation: A Family Key (e.g., KF-1) shall be used to create a
Law Enforcement Access Field (LEAF) in accordance with a LEAF Creation Method (e.g., LCM-1).
The security equipment shall ensure that the LEAF is transmitted in such a manner that the LEAF and
ciphertext may be decrypted with legal authorization. No additional encryption or modification of the
LEAF is permitted. 4.2 PARAMETERS The following parameters shall be used in performing the
prescribed functions: 1. Device Unique Identifier (UID): The identifier unique to a particular device
and used by the Key Escrow System. 2. Device Unique Key (KU): The cryptographic key unique to a
particular device and used by the Key Escrow System. 3. Cryptographic Protocol Field (CPF): The
field identifying the registered cryptographic protocol used by a particular application and used by the
Key Escrow System (reserved for future specification and use). 4. Escrow Authenticator (EA): A
binary pattern that is inserted in the LEAF to ensure that the LEAF is transmitted and received properly
and has not been modified, deleted or replaced in an unauthorized manner. 5. Initialization Vector (IV):
A mode and application dependent vector of bytes used to initialize, synchronize and verify the
encryption, decryption and key escrow functions. 6. Family Key (KF): The cryptographic key stored in
all devices designated as a family that is used to create a LEAF. 7. Session Key (KS): The
cryptographic key used by a device to encrypt and decrypt data during a session. 8. Law Enforcement
Access Field (LEAF): The field containing the encrypted session key and the device identifier and the
escrow authenticator.
5. IMPLEMENTATION
The Cryptographic Algorithm (i.e., SKIPJACK) and a LEAF Creation Method (e.g., LCM-1) shall be
implemented in an electronic device (e.g., VLSI chip) which is highly resistant to reverse engineering
(destructive or non-destructive) to obtain or modify the cryptographic algorithm, the UID, the KF, the
KU, the EA, the CPF, the operational KS, and any other security or Key Escrow System relevant
information. The device shall be able to be programmed/personalized (i.e., made unique) after mass
production in such a manner that the UID, KU (or its components), KF (or its components) and EA
fixed pattern can be entered once (and only once) and maintained without external electrical power.
The LEAF and the IV shall be transmitted with the ciphertext. The specifics of the protocols used to
create and transmit the LEAF, IV, and encrypted data shall be registered and a CPF assigned. The CPF
(and the KF-ID, LCM-ID) shall then be transmitted in accordance with the registered specifications.
Various devices implementing this standard are anticipated. The implementation may vary with the
application. The specific electric, physical and logical interface will vary with the implementation.
Each approved, registered implementation shall have an unclassified electrical, physical and logical
interface specification sufficient for an equipment manufacturer to understand the general requirements
for using the device. Some of the requirements may be classified and therefore would not be specified
in the unclassified interface specification. The device Unique Key shall be composed of two
components (each a minimum of 80 bits long) and each component shall be independently generated
and stored by an escrow agent. The session key used to encrypt transmitted information shall be the
same as the session key used to decrypt received information in a two-way simultaneous
communication. The Lead Creation Method (LCM), the Cryptographic Protocol Field (CPF), and the
Family Key Identifier (KF-ID) shall be registered in the NIST Computer Security Object Register. This
standard is not an interoperability standard. It does not provide sufficient information to design and
implement a security device or equipment. Other specifications and standards will be required to assure
interoperability of EES devices in various applications. Specifications of a particular EES device must
be obtained from the manufacturer. The specifications for the SKIPJACK algorithm are contained in
the R21 Informal Technical Report entitled "SKIPJACK" (S), R21-TECH- 044-91, May 21, 1991. The
specifications for LEAF Creation Method 1 are contained in the R21 Informal Technical Report
entitled "Law Enforcement Access Field for the Key Escrow Microcircuit" (S). Organizations holding
an appropriate security clearance and entering into a Memorandum of Agreement with the National
Security Agency regarding implementation of the standard will be provided access to the classified
specifications. Inquiries may be made regarding the Technical Reports and this program to Director,
National Security Agency, Fort George G. Meade, MD 20755-6000, ATTN: R21. FIPS PUB 186,
1994 MAY 19 FIPS PUB 186, 1994 MAY 19 FIPS PUB 186
Federal Information Processing Standards Publication 186
1994 May 19 U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology
DIGITAL SIGNATURE STANDARD (DSS)
CATEGORY: COMPUTER SECURITY SUBCATEGORY: CRYPTOGRAPHY U.S. DEPARTMENT
OF COMMERCE, Ronald Brown, Secretary NATIONAL INSTITUTE OF STANDARDS AND
TECHNOLOGY, Arati Prabhakar, Director
Foreword
The Federal Information Processing Standards Publication Series of the National Institute of Standards
and Technology (NIST) is the official series of publications relating to standards and guidelines
adopted and promulgated under the provisions of Section 111(d) of the Federal Property and
Administrative Services Act of 1949 as amended by the Computer Security Act of 1987, Public Law
100-235. These mandates have given the Secretary of Commerce and NIST important responsibilities
for improving the utilization and management of computer and related telecommunications systems in
the Federal Government. The NIST, through the Computer Systems Laboratory, provides leadership,
technical guidance, and coordination of Government efforts in the development of standards and
guidelines in these areas. Comments concerning Federal Information Processing Standards
Publications are welcomed and should be addressed to the Director, Computer Systems Laboratory,
National Institute of Standards and Technology, Gaithersburg, MD 20899. James H. Burrows, Director
Computer Systems Laboratory
Abstract
This standard specifies a Digital Signature Algorithm (DSA) which can be used to generate a digital
signature. Digital signatures are used to detect unauthorized modifications to data and to authenticate
the identity of the signatory. In addition, the recipient of signed data can use a digital signature in
proving to a third party that the signature was in fact generated by the signatory. This is known as
nonrepudiation since the signatory cannot, at a later time, repudiate the signature. Key words: ADP
security, computer security, digital signatures, public-key cryptography, Federal Information
Processing Standard. Federal Information Processing Standards Publication 186 1994 May 19
Announcing the DIGITAL SIGNATURE STANDARD (DSS)
Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National
Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant to
Section 111(d) of the Federal Property and Administrative Services Act of 1949 as amended by the
Computer Security Act of 1987, Public Law 100-235. Name of Standard: Digital Signature Standard
(DSS). Category of Standard: Computer Security; Cryptography. Explanation: This Standard specifies
a Digital Signature Algorithm (DSA) appropriate for applications requiring a digital rather than written
signature. The DSA digital signature is a pair of large numbers represented in a computer as strings of
binary digits. The digital signature is computed using a set of rules (i.e., the DSA) and a set of
parameters such that the identity of the signatory and integrity of the data can be verified. The DSA
provides the capability to generate and verify signatures. Signature generation makes use of a private
key to generate a digital signature. Signature verification makes use of a public key which corresponds
to, but is not the same as, the private key. Each user possesses a private and public key pair. Public
keys are assumed to be known to the public in general. Private keys are never shared. Anyone can
verify the signature of a user by employing that user's public key. Signature generation can be
performed only by the possessor of the user's private key. A hash function is used in the signature
generation process to obtain a condensed version of data, called a message digest (see Figure 1). The
message digest is then input to the DSA to generate the digital signature. The digital signature is sent to
the intended verifier along with the signed data (often called the message). The verifier of the message
and signature verifies the signature by using the sender's public key. The same hash function must also
be used in the verification process. The hash function is specified in a separate standard, the Secure
Hash Standard (SHS), FIPS 180. Similar procedures may be used to generate and verify signatures for
stored as well as transmitted data. Approving Authority: Secretary of Commerce. Maintenance
Agency: U.S. Department of Commerce, National Institute of Standards and Technology (NIST),
Computer Systems Laboratory (CSL). Applicability: This standard is applicable to all Federal
departments and agencies for the protection of unclassified information that is not subject to section
2315 of Title 10, United States Code, or section 3502(2) of Title 44, United States Code. This standard
shall be used in designing and implementing public-key based signature systems which Federal
departments and agencies operate or which are operated for them under contract. Adoption and use of
this standard is available to private and commercial organizations. Applications: The DSA
authenticates the integrity of the signed data and the identity of the signatory. The DSA may also be
used in proving to a third party that data was actually signed by the generator of the signature. The
DSA is intended for use in electronic mail, electronic funds transfer, electronic data interchange,
software distribution, data storage, and other applications which require data integrity assurance and
data origin authentication. Implementations: The DSA may be implemented in software, firmware,
hardware, or any combination thereof. NIST is developing a validation program to test
implementations for conformance to this standard. Information about the planned validation program
can be obtained from the National Institute of Standards and Technology, Computer Systems
Laboratory, Attn: DSS Validation, Gaithersburg, MD 20899. Export Control: Implementations of this
standard are subject to Federal Government export controls as specified in Title 15, Code of Federal
Regulations, Parts 768 through 799. Exporters are advised to contact the Department of Commerce,
Bureau of Export Administration for more information. Patents: The Department of Commerce is not
aware of any patents that would be infringed by this standard. Implementation Schedule: This standard
becomes effective December 1, 1994. Specifications: Federal Information Processing Standard
(FIPS186) Digital Signature Standard (DSS), (affixed). Cross Index: a. Federal Information Resources
Management Regulations (FIRMR) subpart 201.20.303, Standards, and subpart 201.39.1002, Federal
Standards. b. FIPS PUB 46-2, Data Encryption Standard. c. FIPS PUB 73, Guidelines for Security of
Computer Applications. d. FIPS PUB 140-1, Security Requirements for Cryptographic Modules. e.
FIPS PUB 171, Key Management Using ANSI X9.17. f. FIPS PUB 180, Secure Hash Standard.
Qualifications: The security of a digital signature system is dependent on maintaining the secrecy of
users' private keys. Users must therefore guard against the unauthorized acquisition of their private
keys. While it is the intent of this standard to specify general security requirements for generating
digital signatures, conformance to this standard does not assure that a particular implementation is
secure. The responsible authority in each agency or department shall assure that an overall
implementation provides an acceptable level of security. This standard will be reviewed every five
years in order to assess its adequacy. Waiver Procedure: Under certain exceptional circumstances, the
heads of Federal departments and agencies may approve waivers to Federal Information Processing
Standards (FIPS). The head of such agency may redelegate such authority only to a senior official
designated pursuant to section 3506(b) of Title 44, United States Code. Waiver shall be granted only
when: a. Compliance with a standard would adversely affect the accomplishment of the mission of an
operator of a Federal computer system; or b. Compliance with a standard would cause a major adverse
financial impact on the operator which is not offset by Government-wide savings. Agency heads may
act upon a written waiver request containing the information detailed above. Agency heads may also
act without a written waiver request when they determine that conditions for meeting the standard
cannot be met. Agency heads may approve waivers only by a written decision which explains the basis
on which the agency head made with required finding(s). A copy of each decision, with procurement
sensitive or classified portions clearly identified, shall be sent to: National Institute of Standards and
Technology; ATTN: FIPS Waiver Decisions, Technology Building, Room B-154, Gaithersburg, MD
20899. In addition, notice of each waiver granted and each delegation of authority to approve waivers
shall be sent promptly to the Committee on Government Operations of the House of Representatives
and the Committee on Government Affairs of the Senate and shall be published promptly in the
Federal Register. When the determination on a waiver applies to the procurement of equipment and/or
services, a notice of the waiver determination must be published in the Commerce Business Daily as a
part of the notice of solicitation for offers of an acquisition or, if the waiver determination is made after
that notice is published, by amendment to such notice. A copy of the waiver, any supporting
documents, the document approving the waiver and any accompanying documents, with such deletions
as the agency is authorized and decides to make under 5 United States Code Section 552(b), shall be
part of the procurement documentation and retained by the agency. Where to Obtain Copies of the
Standard: Copies of this publication are for sale by the National Technical Information Service, U.S.
Department of Commerce, Springfield, VA 22161. When ordering, refer to Federal Information
Processing Standards Publication 186 (FIPSPUB186), and identify the title. When microfiche is
desired, this should be specified. Prices are published by NTIS in current catalogs and other issuances.
Payment may be made by check, money order, deposit account or charged to a credit card accepted by
NTIS. Federal Information Processing Standards Publication XX 1994 May 19
Specifications for the DIGITAL SIGNATURE STANDARD (DSS)
1. INTRODUCTION
This publication prescribes the Digital Signature Algorithm (DSA) for digital signature generation and
verification. Additional information is provided in Appendices 1 through 5.
2. GENERAL
When a message is received, the recipient may desire to verify that the message has not been altered in
transit. Furthermore, the recipient may wish to be certain of the originator's identity. Both of these
services can be provided by the DSA. A digital signature is an electronic analogue of a written
signature in that the digital signature can be used in proving to the recipient or a third party that the
message was, in fact, signed by the originator. Digital signatures may also be generated for stored data
and programs so that the integrity of the data and programs may be verified at any later time. This
publication prescribes the DSA for digital signature generation and verification. In addition, the criteria
for the public and private keys required by the algorithm are provided.
3. USE OF THE DSA ALGORITHM
The DSA is used by a signatory to generate a digital signature on data and by a verifier to verify the
authenticity of the signature. Each signatory has a public and private key. The private key is used in the
signature generation process and the public key is used in the signature verification process. For both
signature generation and verification, the data which is referred to as a message, M, is reduced by
means of the Secure Hash Algorithm (SHA) specified in FIPS YY. An adversary, who does not know
the private key of the signatory, cannot generate the correct signature of the signatory. In other words,
signatures cannot be forged. However, by using the signatory's public key, anyone can verify a
correctly signed message. A means of associating public and private key pairs to the corresponding
users is required. That is, there must be a binding of a user's identity and the user's public key. This
binding may be certified by a mutually trusted party. For example, a certifying authority could sign
credentials containing a user's public key and identity to form a certificate. Systems for certifying
credentials and distributing certificates are beyond the scope of this standard. NIST intends to publish
separate document(s) on certifying credentials and distributing certificates.
4. DSA PARAMETERS
The DSA makes use of the following parameters: 1. p = a prime modulus, where 2L-1 < p < 2L for 512
ó L ó 1024 and L a multiple of 64 2. q = a prime divisor of p - 1, where 2159 < q < 2160 3. g = h(p1)/q mod p, where h is any integer with 1 < h < p - 1 such that h(p-1)/q mod p > 1 (g has order q mod
p) 4. x = a randomly or pseudorandomly generated integer with 0 < x < q 5. y = gx mod p 6. k = a
randomly or pseudorandomly generated integer with 0 < k < q The integers p, q, and g can be public
and can be common to a group of users. A user's private and public keys are x and y, respectively.
They are normally fixed for a period of time. Parameters x and k are used for signature generation only,
and must be kept secret. Parameter k must be regenerated for each signature. Parameters p and q shall
be generated as specified in Appendix 2, or using other FIPS approved security methods. Parameters x
and k shall be generated as specified in Appendix 3, or using other FIPS approved security methods. 5.
SIGNATURE GENERATION The signature of a message M is the pair of numbers r and s computed
according to the equations below: r = (gk mod p) mod q and s = (k-1(SHA(M) + xr)) mod q. In the
above, k-1 is the multiplicative inverse of k, mod q; i.e., (k- 1 k) mod q = 1 and 0 < k-1 < q. The value
of SHA(M) is a 160-bit string output by the Secure Hash Algorithm specified in FIPS 180. For use in
computing s, this string must be converted to an integer. The conversion rule is given in Appendix 2.2.
As an option, one may wish to check if r = 0 or s = 0. If either r = 0 or s = 0, a new value of k should
be generated and the signature should be recalculated (it is extremely unlikely that r = 0 or s = 0 if
signatures are generated properly). The signature is transmitted along with the message to the verifier.
6. SIGNATURE VERIFICATION Prior to verifying the signature in a signed message, p, q and g plus
the sender's public key and identity are made available to the verifier in an authenticated manner. Let
Mþ, rþ, and sþ be the received versions of M, r, and s, respectively, and let y be the public key of the
signatory. To verify the signature, the verifier first checks to see that 0 < rþ < q and 0 < sþ < q; if either
condition is violated the signature shall be rejected. If these two conditions are satisfied, the verifier
computes w = (sþ)-1 mod q u1 = ((SHA(Mþ))w) mod q u2 = ((rþ)w) mod q v = (((g)u1 (y)u2) mod p)
mod q. If v = rþ, then the signature is verified and the verifier can have high confidence that the
received message was sent by the party holding the secret key x corresponding to y. For a proof that v
= rþ when Mþ = M, rþ = r, and sþ = s, see Appendix 1. If v does not equal rþ, then the message may
have been modified, the message may have been incorrectly signed by the signatory, or the message
may have been signed by an impostor. The message should be considered invalid.
APPENDIX 1. A PROOF THAT v = rþ
This appendix is for informational purposes only and is not required to meet the standard. The purpose
of this appendix is to show that if Mþ = M, rþ = r and sþ = s in the signature verification then v = rþ.
We need the following easy result. LEMMA. Let p and q be primes so that q divides p - 1, h a positive
integer less than p, and g = h(p-1)/q mod p. Then gq mod p = 1, and if m mod q = n mod q, then gm
mod p = gn mod p. Proof: We have gq mod p = (h(p-1)/q mod p)q mod p = h(p-1) mod p = 1 by
Fermat's Little Theorem. Now let m mod q = n mod q, i.e., m = n + kq for some integer k. Then gm
mod p = gn+kq mod p = (gn gkq) mod p = ((gn mod p) (gq mod p)k) mod p = gn mod p since gq mod
p = 1. þ We are now ready to prove the main result. THEOREM. If Mþ = M, rþ = r, and sþ = s in the
signature verification, then v = rþ. Proof: We have w = (sþ)-1 mod q = s-1 mod q u1 = ((SHA(Mþ))w)
mod q = ((SHA(M))w) mod q u2 = ((rþ)w) mod q = (rw) mod q. Now y = gx mod p, so that by the
lemma, v = ((gu1 yu2) mod p) mod q = ((gSHA(M)w yrw) mod p) mod q = ((gSHA(M)w gxrw) mod
p) mod q = ((g(SHA(M)+xr)w) mod p) mod q. Also s = (k-1(SHA(M) + xr)) mod q. Hence w =
(k(SHA(M) + xr)-1) mod q (SHA(M) + xr)w mod q = k mod q. Thus by the lemma, v = (gk mod p)
mod q = r = rþ. þ
APPENDIX 2. GENERATION OF PRIMES FOR THE DSA
This appendix includes algorithms for generating the primes p and q used in the DSA. These
algorithms require a random number generator (see Appendix 3), and an efficient modular
exponentiation algorithm. Generation of p and q shall be performed as specified in this appendix, or
using other FIPS approved security methods. 2.1. A PROBABILISTIC PRIMALITY TEST In order to
generate the primes p and q, a primality test is required. There are several fast probabilistic algorithms
available. The following algorithm is a simplified version of a procedure due to M.O. Rabin, based in
part on ideas of Gary L. Miller. [See Knuth, The Art of Computer Programming, Vol. 2, AddisonWesley, 1981, Algorithm P, page 379.] If this algorithm is iterated n times, it will produce a false
prime with probability no greater than 1/4n. Therefore, n ò 50 will give an acceptable probability of
error. To test whether an integer is prime: Step 1. Set i = 1 and n ò 50. Step 2. Set w = the integer to be
tested, w = 1 + 2am, where m is odd and 2a is the largest power of 2 dividing w - 1. Step 3. Generate a
random integer b in the range 1 < b < w. Step 4. Set j = 0 and z = bm mod w. Step 5. If j = 0 and z = 1,
or if z = w - 1, go to step 9. Step 6. If j > 0 and z = 1, go to step 8. Step 7. j = j + 1. If j < a, set z = z2
mod w and go to step 5. Step 8. w is not prime. Stop. Step 9. If i < n, set i = i + 1 and go to step 3.
Otherwise, w is probably prime. 2.2. GENERATION OF PRIMES The DSS requires two primes, p and
q, satisfying the following three conditions: a. 2159 < q < 2160 b. 2L-1 < p < 2L for a specified L,
where L = 512 + 64j for some 0 ó j ó 8 c. q divides p - 1. This prime generation scheme starts by using
the SHA and a user supplied SEED to construct a prime, q, in the range 2159 < q < 2160. Once this is
accomplished, the same SEED value is used to construct an X in the range 2L-1 < X < 2L. The prime,
p, is then formed by rounding X to a number congruent to 1 mod 2q as described below. An integer x
in the range 0 ó x < 2g may be converted to a g-long sequence of bits by using its binary expansion as
shown below: x = x1*2g-1 + x2*2g-2 + ... + xg-1*2 + xg -> { x1,...,xg }. Conversely, a g-long
sequence of bits { x1,...,xg } is converted to an integer by the rule { x1,...,xg } -> x1*2g-1 + x2*2g-2 +
... + xg-1*2 + xg. Note that the first bit of a sequence corresponds to the most significant bit of the
corresponding integer and the last bit to the least significant bit. Let L - 1 = n*160 + b, where both b
and n are integers and 0 ó b < 160. Step 1. Choose an arbitrary sequence of at least 160 bits and call it
SEED. Let g be the length of SEED in bits. Step 2. Compute U = SHA[SEED] XOR SHA[(SEED+1)
mod 2g ]. Step 3. Form q from U by setting the most significant bit (the 2159 bit) and the least
significant bit to 1. In terms of boolean operations, q = U OR 2159 OR 1. Note that 2159 < q < 2160.
Step 4. Use a robust primality testing algorithm to test whether q is prime1. Step 5. If q is not prime, go
to step 1. Step 6. Let counter = 0 and offset = 2. Step 7. For k = 0,...,n let Vk = SHA[(SEED + offset +
k) mod 2g ]. 1A robust primality test is one where the probability of a non-prime number passing the
test is at most 2-80. Step 8. Let W be the integer W = V0 + V1*2160 + ... + Vn-1*2(n-1)*160 + (Vn
mod 2b) * 2n*160 and let X = W + 2L-1. Note that 0 ó W < 2L-1 and hence 2L-1 ó X < 2L. Step 9.
Let c = X mod 2q and set p = X - (c - 1). Note that p is congruent to 1 mod 2q. Step 10. If p < 2L-1,
then go to step 13. Step 11. Perform a robust primality test on p. Step 12. If p passes the test performed
in step 11, go to step 15. Step 13. Let counter = counter + 1 and offset = offset + n + 1. Step 14. If
counter ò 212 = 4096 go to step 1, otherwise (i.e. if counter < 4096) go to step 7. Step 15. Save the
value of SEED and the value of counter for use in certifying the proper generation of p and q.
APPENDIX 3. RANDOM NUMBER GENERATION FOR THE DSA
Any implementation of the DSA requires the ability to generate random or pseudorandom integers.
Such numbers are used to derive a user's private key, x, and a user's per message secret number, k.
These randomly or pseudorandomly generated integers are selected to be between 0 and the 160-bit
prime q (as specified in the standard). They shall be generated by the techniques given in this
appendix, or using other FIPS approved security methods. One FIPS approved pseudorandom integer
generator is supplied in Appendix C of ANSI X9.17, "Financial Institution Key Management
(Wholesale)." Other pseudorandom integer generators are given in this appendix. These permit
generation of pseudorandom values of x and k for use in the DSA. The algorithm in section 3.1 may be
used to generate values for x. An algorithm for k and r is given in section 3.2. The latter algorithm
allows most of the signature computation to be precomputed without knowledge of the message to be
signed. The algorithms employ a one-way function G(t,c), where t is 160 bits, c is b bits (160 ó b ó
512) and G(t,c) is 160 bits. One way to construct G is via the Secure Hash Algorithm (SHA), as
defined in the Secure Hash Standard (SHS). The 160-bit message digest output of the SHA algorithm
when message M is input is denoted by SHA(M). A second method for constructing G is to use the
Data Encryption Standard (DES). The construction of G by these techniques is discussed in sections
3.3 and 3.4 of this appendix. In the algorithms in sections 3.1 and 3.2, a secret b-bit seed-key is used.
The algorithm in section 3.1 optionally allows the use of a user provided input. If G is constructed via
the SHA as defined in section 3.3, then b is between 160 and 512. If DES is used to construct G as
defined in section 3.4, then b is equal to 160. 3.1. ALGORITHM FOR COMPUTING m VALUES OF
x Let x be the signer's private key. The following may be used to generate m values of x: Step 1.
Choose a new, secret value for the seed-key, XKEY. Step 2. In hexadecimal notation let t = 67452301
EFCDAB89 98BADCFE 10325476 C3D2E1F0. This is the initial value for H0 || H1 || H2 || H3 || H4 in
the SHS. Step 3. For j = 0 to m - 1 do a. XSEEDj = optional user input. b. XVAL = (XKEY + XSEEDj)
mod 2b. c. xj = G(t,XVAL) mod q. d. XKEY = (1 + XKEY + xj) mod 2b. 3.2. ALGORITHM FOR
PRECOMPUTING ONE OR MORE k AND r VALUES This algorithm can be used to precompute k,
k-1, and r for m messages at a time. Algorithm: Step 1. Choose a secret initial value for the seed-key,
KKEY. Step 2. In hexadecimal notation let t = EFCDAB89 98BADCFE 10325476 C3D2E1F0
67452301. This is a cyclic shift of the initial value for H0 || H1 || H2 || H3 || H4 in the SHS. Step 3. For
j = 0 to m - 1 do a. k = G(t,KKEY) mod q. b. Compute kj-1 = k-1 mod q. c. Compute rj = (gk mod p)
mod q. d. KKEY = (1 + KKEY + k) mod 2b. Step 4. Suppose M0 , ... , Mm-1 are the next m messages.
For j = 0 to m - 1 do a. Let h = SHA(Mj). b. Let sj = (kj-1(h + xrj)) mod q. c. The signature for Mj is
(rj,sj). Step 5. Let t = h. Step 6. Go to step 3. Step 3 permits precomputation of the quantities needed to
sign the next m messages. Step 4 can begin whenever the first of these m messages is ready. The
execution of step 4 can be suspended whenever the next of the m messages is not ready. As soon as
steps 4 and 5 have completed, step 3 can be executed, and the results saved until the first member of
the next group of m messages is ready. In addition to space for KKEY, two arrays of length m are
needed to store r0 , ... rm-1 and k0-1, ... , km-1-1 when they are computed in step 3. Storage for s0 , ...
, sm-1 is only needed if the signatures for a group of messages are stored; otherwise sj in step 4 can be
replaced by s and a single space allocated. 3.3. CONSTRUCTING THE FUNCTION G FROM THE
SHA G(t,c) may be constructed using steps (a) - (e) in section 7 of the Specifications for the Secure
Hash Standard. Before executing these steps, {Hj} and M1 must be initialized as follows: i. Initialize
the {Hj} by dividing the 160 bit value t into five 32-bit segments as follows: t = t0 || t1 || t2 || t3 || t4
Then Hj = tj for j = 0 through 4. ii. There will be only one message block, M1, which is initialized as
follows: M1 = c || 0512-b (The first b bits of M1 contain c, and the remaining (512-b) bits are set to
zero). Then steps (a) through (e) of section 7 are executed, and G(t,c) is the 160 bit string represented
by the five words: H0 || H1 || H2 || H3 || H4 at the end of step (e). 3.4. CONSTRUCTING THE
FUNCTION G FROM THE DES Let a XOR b denote the bitwise exclusive-or of bit strings a and b.
Suppose a1, a2, b1, b2 are 32-bit strings. Let b1' be the 24 least significant bits of b1. Let K = b1' || b2
and A = a1 || a2. Define DESb1,b2(a1,a2) = DESK(A) In the above, DESK(A) represents ordinary DES
encryption of the 64- bit block A using the 56-bit key K. Now suppose t and c are each 160 bits. To
compute G(t,c): Step 1. Write t = t1 || t2 || t3 || t4 || t5 c = c1 || c2 || c3 || c4 || c5 In the above, each ti and
ci is 32 bits. Step 2. For i = 1 to 5 do xi = ti XOR ci Step 3. For i = 1 to 5 do b1 = c((i+3) mod 5) + 1
b2 = c((i+2) mod 5) + 1 a1 = xi a2 = x(i mod 5) + 1 XOR x((i+3) mod 5) + 1 yi,1 || yi,2 =
DESb1,b2(a1,a2) (yi,1, yi,2 = 32 bits) Step 4. For i = 1 to 5 do zi = yi,1 XOR y((i+1) mod 5)+1,2 XOR
y((i+2) mod 5)+1,1 Step 5. Let G(t,c) = z1 || z2 || z3 || z4 || z5
APPENDIX 4. GENERATION OF OTHER QUANTITIES
This appendix is for informational purposes only and is not required to meet the standard. The
algorithms given in this appendix may be used to generate the quantities g, k-1, and s-1 used in the
DSS. To generate g: Step 1. Generate p and q as specified in Appendix 2. Step 2. Let e = (p - 1)/q. Step
3. Set h = any integer, where 1 < h < p - 1 and h differs from any value previously tried. Step 4. Set g =
he mod p. Step 5. If g = 1, go to step 3. To compute the multiplicative inverse n-1 mod q for n with 0 <
n < q, where 0 < n-1 < q: Step 1. Set i = q, h = n, v = 0, and d = 1. Step 2. Let t = i DIV h, where DIV is
defined as integer division. Step 3. Set x = h. Step 4. Set h = i - tx. Step 5. Set i = x. Step 6. Set x = d.
Step 7. Set d = v - tx. Step 8. Set v = x. Step 9. If h > 0, go to step 2. Step 10. Let n-1 = v mod q. Note
that in step 10, v may be negative. The v mod q operation should yield a value between 1 and q - 1
inclusive. APPENDIX 5. EXAMPLE OF THE DSA This appendix is for informational purposes only
and is not required to meet the standard. Let L = 512 (size of p). The values in this example are
expressed in hexadecimal notation. The p and q given here were generated by the prime generation
standard described in appendix 2 using the 160- bit SEED: d5014e4b 60ef2ba8 b6211b40 62ba3224
e0427dbd With this SEED, the algorithm found p and q when the counter was at 38. x was generated
by the algorithm described in appendix 3, section 3.1, using the SHA to construct G (as in appendix 3,
section 3.3) and a 160-bit XSEED: XSEED = bd029bbe 7f51960b cf9edb2b 61f06f0f eb5a38b6 t =
67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0 x = G(t,XSEED) mod q k was generated by
the algorithm described in appendix 3, section 3.2, using the SHA to construct G (as in appendix 3,
section 3.3) and a 160-bit KSEED: KSEED = 687a66d9 0648f993 867e121f 4ddf9ddb 01205584 t =
EFCDAB89 98BADCFE 10325476 C3D2E1F0 67452301 k = G(t,KSEED) mod q Finally: h = 2 p =
d411a4a0 e393f6aa b0f08b14 d1845866 5b3e4dbd ce254454 3fe365cf 71c86224 12db6e7d d02bbe13
d88c58d7 263e9023 6af17ac8 a9fe5f24 9cc81f42 7fc543f7 q = b20db0b1 01df0c66 24fc1392
ba55f77d 577481e5 g = b3085510 021f9990 49a9e7cd 3872ce99 58186b50 07e7adaf 25248b58
a3dc4f71 781d21f2 df89b717 47bd54b3 23bbecc4 43ec1d3e 020dadab bf782257 8255c104 x =
6b2cd935 d0192d54 e2c942b5 74c80102 c8f8ef67 k = 79577ddc aafddc03 8b865b19 f8eb1ada
8a2838c6 kinv = 2784e3d6 72d972a7 4e22c67f 4f4f726e cc751efa M = ASCII form of "abc" (See
FIPS PUB YY, Appendix A) SHA(M) = 0164b8a9 14cd2a5e 74c4f7ff 082c4d97 fledf880 y =
b32fbec0 3175791d f08c3f86 1c81df7d e7e0cba7 f1c4f726 9bb12d6c 628784fb 742e66ed 315754df
e38b5984 e94d3725 37f655cb 3ea4767c 878cbd2d 783ee662 r = 9b77f705 4c81531c 4e46a469
2fbfe0f7 7f7ebff2 s = 95b4f608 1f8f890e 4b5a199e f10ffe21 f52b2d68 w = 0ceb5f6b 875f6b67
7e093134 df70b0d4 3226680c u1 = 347089a2 9897273b fc7a774f a70e0e0e 153bcc95 u2 = 793d9312
a41b88af aa2c1bd9 49ec3bee 2e75d2f5 gu1 mod p = 57a198ab 2c8ea0b6 4810767a ff732fb2 da5fcafb
278889f1 96b60b9c 1285b848 1d08505e 201a5c68 523a15ee 2fb62a56 d141dc4d 71925ef0 6acde0a5
b89c5671 yu2 mod p = 5d983d20 be604e23 fb19bec8 7860490a 41b865dc 0f5623f4 0724a795
021bcd8c 93a39ddf 51cae380 fb6d682a 676608f7 65227ff0 5e44ccf4 9767e4a6 0832d33f v =
9b77f705 4c81531c 4e46a469 2fbfe0f7 7f7ebff2 --------------