fips171.txt

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

     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