FIPS PUB xyz


                                              	FEDERAL INFORMATION
                                 	PROCESSING STANDARDS PUBLICATION

                                    	(Date)




	U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology









	KEY RECOVERY STANDARD (KRS)

	(DRAFT)










	
	CATEGORY:  COMPUTER SECURITY, CRYPTOGRAPHY




	
	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 5131 of the Information Technology Management Reform Act 
of 1996, and the Computer Security Act of 1987, Public Law 104-106. Under these 
mandates, the Secretary of Commerce promulgates standards and guidance 
pertaining to the efficiency, security and privacy of Federal computer systems. 
The National Institute of Standards and Technology, through its Information 
Technology Laboratory, has the mission of developing standards, guidelines and 
associated methods and techniques for computer systems, and providing technical 
assistance to industry and government  in the implementation of standards.

Comments concerning Federal Information Processing Standards Publications are 
welcomed and should be addressed to the Director, Information Technology 
Laboratory, National Institute of Standards and Technology, Gaithersburg, MD 
20899.


	Shukri Wakid, Director
	Information Technology Laboratory 


	Abstract

This standard specifies requirements to be met by government Key Recovery 
Systems. Such systems provide for the decryption of stored or communicated data 
when access to the data is properly authorized.

ALTERNATIVE TO THE ABOVE: This standard specifies requirements to be met by key 
recovery components used by Federal government agencies. These components 
provide for the recovery of keys which will be used for the decryption of stored 
or communicated data when access to the data is properly authorized.

Key words: ADP security, computer security, Key Recovery, Federal Information 
Processing Standard.


                                                  	FIPS PUB xyz


	Federal Information
	Processing Standards Publication XXX

	(Date)

	Announcing the 

	KEY RECOVERY STANDARD (KRS)


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 5131 of the Information Technology 
Management Reform Act of 1996, and the Computer Security Act of 1987, Public Law 
104-106.

1.	Name of Standard. Key Recovery Standard (KRS).

2.	Category of Standard. Computer Security, Cryptography.

3.	Explanation. This Standard specifies requirements for key recovery 
components. These components provide for the recovery of keys to be used for the 
decryption of stored or communicated ciphertext when the decryption keys are not 
otherwise available.  Key recovery is motivated by three primary scenarios:

1. recovery of stored data on behalf of an organization (or individual) e.g., in 
response to accidental loss of keys;
2. recovery of stored or communicated data on behalf of an organization (e.g., 
for the purposes of monitoring or auditing activities); and
3. recovery of communicated or stored data by lawfully authorized authorities.

The first scenario supports the ability to regain access to data that would 
otherwise be lost.  The second scenario encompasses internal investigation 
authorized by an organization. The final scenario encompasses data acquired 
under the authorization of court orders for wiretaps, search and seizure orders, 
civil suit subpoenas, etc

[NOTE: I'M HAVING TROUBLE DIFFERENTIATING BETWEEN THE USES OF KRS - KEY RECOVERY 
STANDARD AND KEY RECOVERY SYSTEM. PLEASE PROVIDE GUIDANCE.]

A Key Recovery System (KRS) manages cryptographic keys in support of data 
recovery when normal key access mechanisms fail.  These systems must be 
carefully designed so that plaintext may be recovered in a timely manner, and so 
that only authorized recoveries are permitted.  Therefore, security is a 
critical factor in any KRS design.

The purpose of this standard is to specify requirements for key recovery 
components, and to enable the validation of components claiming conformance.  
The standard encompasses the security (from an implementation, managerial and 
operation perspective) and the availability of key recovery components, as well 
as defining interoperability requirements.

4.	Approving Authority. Secretary of Commerce.

5.	Maintenance Agency. U.S. Department of Commerce, National Institute of 
Standards and Technology (NIST), Information Technology Laboratory.

6.	Cross Index.
 a. FIPS PUB 46-2, Data Encryption Standard.
 b. FIPS PUB 81, DES Modes of Operation.
 c. FIPS PUB 140-1, Security Requirements for Cryptographic Modules.

Other NIST publications may be applicable to the implementation and use of this 
standard. A list (NIST Publications List 91) of currently available computer 
security publications, including ordering information, can be obtained from 
NIST.

7.	Applicability.  This standard is applicable to all Federal departments and 
agencies and their contractors.  This standard shall be used in designing, 
acquiring and implementing encryption and key recovery components and systems 
that Federal departments and agencies use or operate, or which are operated for 
them under contract.  Components that implement cryptography for purposes other 
than general encryption (e.g., digital signatures, password encryption, or 
access control techniques) are outside the scope of this standard. To prevent 
the recovery of cryptographic keys used for these other purposes, it is 
incumbent on the user to ensure that different keys are used for encryption than 
are used for other purposes (e.g., digital signatures).

This standard shall apply to systems when both of the following are true:

a. Encryption is or will be employed to achieve the confidentiality of 
communicated or stored data.
b. The data protected by encryption are not classified according to Executive 
Order 12356, entitled "National Security Information," or to its successor 
orders, or to the Atomic Energy Act of 1954, amended.

Systems in Federal departments or agencies that process data classified 
according to either of the acts cited in "b" above may employ encryption devices 
approved for classified data protection in order to protect unclassified data in 
lieu of this standard.

This standard supersedes FIPS 185.  However, components which have been built to 
conform to FIPS 185 are still approved for U.S. Government use.  The SKIPJACK 
encryption algorithm and the Key Exchange Algorithm used by FIPS 185 components 
continue to be FIPS approved.

This standard and components conforming to this standard, may be adopted and 
used by non-Federal Government organizations on a voluntary basis.

8.	Applications. This standard is appropriate for use in a variety of 
applications, including:

1. When computer files are encrypted for secure storage or transmission;
2. When electronic mail is encrypted before transmission among communicating 
entities; and
3. When electronic voice communications are encrypted for privacy.

9.	Specifications. Federal Information Processing Standard (FIPS xyz) Key 
Recovery Standard (affixed).

10.	Implementations. System components, or parts thereof, conforming to this 
standard may be implemented in software, firmware, hardware, or any combination 
thereof. All cryptographic modules employed in components of such systems shall 
comply with FIPS 140-1.  FIPS approved encryption algorithms (e.g., DES) shall 
be used in Federal applications of systems conforming to this standard.  The use 
of new encryption algorithms which are FIPS approved after the date of the 
standard is also permitted.

Information about the validation of implementations conforming to this standard 
may be found in Section X of the attached Specification.  Additional information 
may be obtained from the National Institute of Standards and Technology, 
Information Technology Laboratory, Attn: Key Recovery Validation, Gaithersburg, 
MD 20899.

11.	Export Control. Implementations of this standard are subject to export 
controls as specified in Title 15, Code of Federal Regulations, Parts 730-774 
and Title 22, Code of Federal Regulations, Parts 120-130.  Exporters are advised 
to contact the Encryption Policy Controls Division at the Department of 
Commerce, Bureau of Export Administration for more information.

12.	Patents. Implementations of this standard may be covered by U.S. and 
foreign patents.

13.	Implementation Schedule. The effective date of this standard is <insert 
date>.  From approval of this FIPS by the Secretary of Commerce to its effective 
date, agencies may purchase components that have been affirmed in writing from 
the manufacturer as complying with this standard.  From the effective date until 
six months after the establishment of the validation program by NIST, agencies 
that have determined a need for key recovery components shall purchase 
components that have been affirmed in writing by the manufacturer as complying 
with this standard.  A copy of the written affirmation shall have been sent to 
the Director, Information Technology Laboratory, National Institute of Standards 
and Technology, Gaithersburg, MD 20899.



For a one year period following the six month period after the establishment of 
the validation program, agencies shall purchase validated key recovery 
components, or components that have been submitted for validation. After this 
period, only validated key recovery components will be considered as meeting the 
provisions of this standard. 

14.	Glossary. The following terms are used as defined below for purposes of 
this standard: 

Assurance
(1) Confidence that an entity meets its security objectives. (2) The degree of 
confidence that a product correctly implements the security policy.

Authentic Public Key Source
Used to provide a certificate infrastructure to support the use of public key 
cryptography within the Key Recovery System.

Authorized key recovery
Key recovery either with the permission of the owner of the data or as otherwise 
permitted by law.

Authorized Request
A request based on a legal and lawful right for access.

Common Criteria (CC)
An international standard for security in information security components.
Common Criteria Evaluation Assurance Level (EAL)

A predefined set of assurance components that represents a point on the CC 
assurance scale.
Common Criteria Protection Profile
An implementation-independent set of security requirements for a category of 
components which meet specific consumer needs.

Confidentiality
(1) Assurance that the information is not disclosed to unauthorized entities or 
processes. (2) The property that sensitive information is not disclosed to 
unauthorized individuals, entities or processes. (3) The property that 
information is not made available or disclosed to an unauthorized user, process 
or object.

Configurable Capability

A capability which is available but need not be selected for use.

Configuration Item
Items (e.g., documents, software, hardware) which are under configuration 
control.

Configuration Management (CM)
The management of security features and assurances through the control of 
changes made to a system's hardware, software, firmware, documentation set, 
test, test fixtures and test documentation throughout the development and 
operational life of the system.

Cryptographic subsystem
Provides a set of cryptographic services (e.g., encryption and decryption) to an 
application.

Data
Voice, facsimile, computer files, electronic mail, and other stored or 
communicated information. 

Data Encryption Key (DEK)

A symmetric key used to encrypt data.
Data recovery
Decryption of encrypted data with the aid of at least one data recovery agent.

Data Recovery Field (DRF)

Change to Key Recovery Field.
Data Recovery System
The system/subsystem used to recover encrypted data using a recovered key 
obtained by the Key Recovery Requestor System.

Decryption
(1) Transformation of ciphertext form of data to plaintext form. (2) The process 
of changing ciphertext into plaintext.

Encapsulated Key Recovery
A method of key recovery where keys, key parts or key related information is 
maintained outside a Key Recovery Agent. Some of the Key Recovery Information is 
wrapped so that it is protected against disclosure when it is stored outside a 
security perimeter.

Encryption
(1) Transformation of plaintext form of data to ciphertext form. (2) A process 
of transforming plaintext into ciphertext for the purpose of security or 
privacy. (3) Transforming text into code in order to conceal its meaning.  The 
process of transforming data to an unintelligible form in such a way that the 
original data either cannot be obtained (one-way encryption), or cannot be 
obtained without using the inverse decryption process. (3) Conversion of 
plaintext to ciphertext through the use of a cryptographic algorithm.

End User System
A system containing the user application and the encryption mechanism used to 
secure that application.  The end user system is supported by the key recovery 
system (i.e., the end user system may include key recovery components,  or 
another system may provide key recovery on behalf of the end user system). The 
encryption mechanism is controlled in accordance with key recovery policy.

Escrow Key Recovery
A method of key recovery where the keys, key parts or key related information to 
be recovered is stored by one or more Key Recovery Agents. Other Key Recovery 
Information may be available elsewhere.

FIPS compliant
Meeting all requirements of the FIPS for a given tier.

Flaw Hypothesis
A system analysis and penetration technique in which specifications and 
documentation for the system are analyzed, and flaws in the system are 
hypothesized.

Flaw Remediation
The correction of discovered security flaws in a product or system.

Functional Requirements

A high level description of the requirements for a system.
Functional Specification
High level description of the user-visible interface and behavior of a system.


Implementation Representation
A description of the implementation (e.g., source code when the implementation 
is software or firmware; or drawings and schematics, if the system is hardware).

Independent Testing

Testing performed by persons other than the developers.
Informal Security Policy Model
An accurate and concise statement of system security policy expressed informally 
(i.e., in natural language; e.g., English).

Informal
(1) Expressed in natural language. (2) Written as prose in natural language.

Informal style/presentation


Integrity
The property that sensitive data has not been modified or deleted in an 
unauthorized and undetected manner.

 Interactive communication


Interoperability
The ability of components to communicate with one another.

Key Encapsulation
The encryption of one cryptographic key by another key. See "Wrap".

Key Encryption Key (KEK)
A key used to encrypt another key. May be a symmetric key, or the public key of 
an encryption public/private key pair.

Key Escrow
(1) The processes of managing (e.g., generating, storing, transferring, 
auditing) the cryptographic keys or key components by one or more entities.


Key Exchange Field


Key-recoverable Product
An encryption product whose encryption output is recoverable through key 
recovery.

Key Recovery
Access to information sufficient to recover encrypted data.

Key Recovery Agent (KRA)
(1) An organization which provides information which facilitates key recovery. 
(2) A trusted entity which possesses information that can be used either 
directly or with other information to recover a key. (3) A trusted entity who 
performs a recovery service in response to an authorized request.

Key Recovery Agent (KRA) System

A key recovery system that performs a recovery service in response to an 
authorized request by a requestor system on behalf of a requestor.
Key Recovery Component
An element within a Key Recovery System that provides key recovery functionality 
(e.g., KRI generation, KRI management, and/or key recovery function).
Key Recovery Field (KRF)
Key recovery information which is specific to a single key recovery scheme.

Key Recovery Function

Recovers a data encrypting key using Key Recovery Information.
Key Recovery Information (KRI)
Information that is used in the recovery of a key. The KRI does not include a 
plaintext key.

Key Recovery Block (KRB)
A stream of bytes that serves as a container for a single key recovery scheme-
specific KRF and associates the KRF with a set of standard fields in a 
predefined format.

Key Recovery Policy
A policy which specifies the conditions under which key recovery information 
must be created and conditions under which and to whom the key recovery 
information may be released; may also indicate the allowable Key Recovery 
Agent(s) and how or where key recovery information must be maintained.

Key Recovery Requestor System
The system/subsystem used by the requestor to request keys.
Key Recovery Service


Key Recovery System (KRS)
Consists of the KRI Generation Function, the KRI Management Function and the Key 
Recovery Function. Includes software, hardware, procedures and infrastructure.

KRI Generation Function
Generates or supplies Key Recovery Information to the KRI Management Function.

KRI Management Function
Assembles and formats the Key Recovery (KRI)  and makes the KRI available to the 
Key Recovery Function.

KRI Providers
Those entities within the KRI Generation Function that provide Key Recovery 
Information (KRI) to the KRI Management Function.

KRR
Key Recovery Requestor.

Least Abstract Representation
The most concrete representation of an implementation (e.g., source code).

Licensing Agent
Authorizes Key Recovery Agents after an evaluation against the FIPS.

Masquerading
An attempt to gain access to a system by posing as an authorized user.

Message Security Protocol (MSP)
A data format that cryptographically binds data sensitivity and provides public 
key cryptography based security services for the data, including 
confidentiality, integrity, etc.

MIME
Multipurpose Internet Mail Extension

Non-key-recoverable Product
An encryption product whose encryption output is not recoverable through key 
recovery.

Partial Key Escrow


Presentation of Evidence


Privacy Enhanced Mail

Communications protocol defined in RFCs 1421 through 1424.
Private Key
(1) In an asymmetric (public) key cryptosystem, that key of an entity's key pair 
which is known only by that entity. (2) A cryptographic key used with a public 
key cryptographic algorithm, uniquely associated with an entity, and not made 
public.

Private Key Recovery
A Key Recovery technique which is used to recover the private key of a public 
key pair or the secret key used with a symmetric encryption algorithm.

Public Key
(1) In an asymmetric key system, that key of an entity's key pair which is 
publicly known. (2) A cryptographic key used with a public key cryptographic 
algorithm, uniquely associated with an entity, and which may be made public.

Receiver Verification
The ability of a recipient's implementation to verify, with high assurance, that 
the originating implementation has implemented FIPS compliant recovery.

Recovery Field
A field, output by the key recovery mechanism of a product, which identifies key 
recovery agents and enables key recovery agents to identify the key(s) required 
to decrypt corresponding ciphertext output by the product. Note that this 
definition may currently be different from the definition for "Key Recovery 
Field" .

Recovery Information

See Key Recovery Information.
Recovery subsystem
The physical components of a KRS which provide for the recovery of plaintext 
when legally authorized.

Registration Agent
Archives vendor-specific information in order to find, acquire and parse 
recovery information.

Representation Correspondence
An accurate and complete mapping from a higher level representation to a lower 
level representation (e.g., from functional requirements to a functional 
specification, from a functional specification to a high level design, from a 
high level design to a low level design, from a low level design to source code, 
etc.).

Requestor
The entity that is authorized to request a key recovery.

Requestor Function
Interacts with one or more Key Recovery Agents using Key Recovery Information to 
recover a data encrypting key.

Secret Key
A cryptographic key used with a secret key [symmetric] cryptographic algorithm, 
uniquely associated with one or more entities, and which shall not be made 
public.

Secret Sharing


Security Policy
(1) A precise specification of the security rules under which a cryptographic 
module may operate, including the security rules derived from the requirements 
of this standard and the additional security rules imposed by the manufacturer. 
(2) A set of rules and procedures regulating the use of information including 
its processing, storage, distribution and presentation.

Security Policy Enforcing Subsystem


Security Policy Model

A formal representation of the security policy enforced by the product.
Session-based Protocols


Session-establishment Protocol


Session Key
A key that is used to encrypt and/or decrypt data for a single communications 
session.

Session Key Recovery

Recovery of the Data Encryption Key.
S/MIME
Secure MIME

Standard Communication Protocol

Any communication protocol adopted by a generally recognized standards 
organization.
Store-and-Forward Communications


System
Includes software, hardware, procedures.

Testing laboratory
A laboratory which has been accredited by NIST to test systems, subsystems, key 
recovery agents, or components for conformance to this standard.

Transaction-based Protocols


Trusted Third Party
An entity which is trusted by the parties performing the encryption or 
decryption processes, but are not identical with those parties.

Unwrap
Decryption of an encrypted key by another key.

Vulnerability Analysis

The determination of the vulnerabilities of a product or system.
Wrap
Encryption of a cryptographic key by another key
			
15.	Qualifications. The security requirements specified in this standard are 
based upon information provided by many sources within the Federal government 
and private industry. The requirements are designed to protect against 
adversaries mounting cost-effective attacks on unclassified government or 
commercial data. The primary goal in defining effective security for a system is 
to make the cost of any attack greater than the possible payoff.

While the security requirements specified in this standard are intended to 
maintain the security of a key recovery component, conformance to this standard 
does not guarantee that a particular component is secure. It is the 
responsibility of the manufacturer of a key recovery component to build the 
component in a secure manner.

Similarly, the use of a key recovery component that conforms to this standard in 
an overall system does not guarantee the security of the overall system. The 
responsible authority in each agency shall assure that an overall system 
provides an acceptable level of security.

Since a standard of this nature must be flexible enough to adapt to advancements 
and innovations in key recovery technology, this standard will be initially 
reviewed in two years in order to consider new or revised requirements that may 
be needed to meet technological changes. 

16.	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.  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 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, Building 225 Building, Room A-231, Gaithersburg, MD 20899.

In addition, a 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 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. Sec. 552(b), shall be 
part of the procurement documentation and retained by the agency.

17.	Where to Obtain Copies of the Standard. Copies of this publication are for 
sale by the National Technical Information Service (NTIS), U.S. Department of 
Commerce, Springfield, VA 22161.  Publication and ordering information may be 
found at http://www.ntis.gov. When ordering, refer to Federal Information 
Processing Standards Publication xyz (FIPS PUB XXX), 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, credit card or deposit account.
DRAFT	02/18/98	DRAFT

	1


13