fips171.txt

《应用密码学》协议、算法与C原程序(第二版)配套源码。很多人都需要的

           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