9 June 1997
Source: http://csrc.nist.gov/krdp/

# KEY RECOVERY DEMONSTRATION PROJECT

### Formerly known as the Emergency Access Demonstration Project

In May 1996, the Office of Management and Budget (OMB) released a white paper titled "Enabling Privacy, Commerce, Security, and Public Safety in the Global Information Infrastructure". This paper stated that "government and industry must work together to create a security management infrastructure and attendant products that incorporate robust cryptography without undermining national security and public safety". In support of this goal, a Key Recovery Demonstration Project (KRDP) was initiated in order to demonstrate the practicability of the recovery of keys that support data encryption in Federal government applications. Approximately ten Federal agencies will participate in a pilot program in which different key recovery technologies will be implemented, tested, and evaluated. A brief description of the pilot agency applications is found in an KRDP Project Summary.

The National Institute Of Standards and Technology (NIST) has issued a Broad Agency Announcement (BAA) that solicits products and services that will be used to support this project. Three possible methods of key recovery are depicted in Key Recovery Examples.

KRDP Implementation Evaluation Criteria identify the functional and security concerns related to the Federal governments's need to have emergency access to encrypted data.

The following additional documents may be useful to contracting organizations that are responding to the BAA.

1. FIPS 140-1

   In January 1994, NIST issued "Security Requirements for Cryptographic Modules" as Federal Information Processing Standard (FIPS) 140-1. The standard specifies the security requirements that are to be satisfied by a cryptographic module utilized within a security system protecting unclassified information within computer and telecommunication systems. When applicable, responders to the BAA are asked to provide FIPS 140-1 compliance status for their offered product or service; however, compliance with FIPS 140-1 is not required for participation in this project.

2. Minimum Interoperability Specification for PKI Components

   A Certification Authority (CA) system certifies the public key that is part of a public/private key pair that can be used to support data encryption. Vendors of CA systems that are responding to the BAA are asked to state to what extent their product or service complies with the NIST draft "Minimum Interoperability Specification for PKI components" which was issued for public comment in December,1996.

## KRDP Project Summary

Until recently, federal agencies have not made significant use of commercial cryptography to protect sensitive unclassified information. However, as federal agencies have begun to realize the sensitivity of their information and that cryptography can help protect that information, more agencies are making use of encryption mechanisms. As encryption becomes more prominent, providing a means for management and other authorized entities to recover keys in the event that a user is away on vacation or is terminated from employment will become critical to the continued operation of each organization. Key recovery (also known as emergency access) is a security service which allows for the decryption of encrypted information through the retrieval of information required to implement that mechanism. Key recovery ensures that mechanisms are in place for management and other authorized entities to recover encrypted information.

The Interagency Working Group on Cryptography Policy (IWG) has established a task group to demonstrate the practicability of key recovery as an element of a key management infrastructure/public key infrastructure (KMI/PKI). The Task Group is formed jointly of representatives from the Government Information Technology Services Board (GITS) and the IWG. The Task Group is chaired by a representative from the Department of the Treasury, who also serves as the Champion for Security and Privacy for the GITS Board with participation from NIST, FBI, NSA, and GSA and each agency with a pilot selected from this demonstration.

Ten Federal agency pilots will test the elements of the vision laid out in the white paper, "Enabling Privacy, Commerce, Security and Public Safety in the Global Information Infrastructure." In addition, the pilots have been selected based on their ability to:

- be a meaningful and readily understood application, but not necessarily mission-critical;
- be capable of being implemented and evaluated in 9 - 15 months;
- use commercial products, to the extent available.

The following presents a brief description of each candidate agency's pilot:

The Department of Energy's (DOE) Office of Energy Research EDI/Internet Security project will test emerging security technologies for Electronic Data Interchange (EDI) that are based on the Internet standards for secure e-mail. Participants include six Federal agencies and eight academic research organizations currently involved in Electronic Research Administration (ERA). The project will test the interoperability of multiple vendors' products across an open systems environment. The initial implementation will focus on processing electronic grant application requirements. Point of Contact: Jean Morrow, jean.morrow@mailgw.er.doe.gov

The U.S. Electronic Grants pilot project will demonstrate that a secure electronic grants system can be built around low cost, World Wide Web technology while maintaining the standard EDI structure required for government-wide data sharing. The Department of Transporation (DOT) Federal Railroad Administration will lead the project in cooperation with its Electronic Grants partners including the Federal Highway Administration, Federal Transit Administration, Federal Aviation Administration, U.S. Coast Guard, Department of Energy, Department of Education, Department of Interior, Office of Naval Research, Environmental Protection Agency, and Small Business Administration. In fiscal year 1995, approximately $300 billion in grants were awarded government wide to support research and development, environmental protection, education, transportation safety, economic development, improved public health and similar programs. DOT and its partners will pilot this application with a small segment of grantees that represent universities, state and local governments and non-profit organizations. Point of Contact: Bradley Smith, bradley.smith@fra.dot.gov

The Lawrence Livermore National Laboratory (LLNL) is in the process of building a Public Key Infrastructure (PKI) to support both its Programmatic and Business operations. Part of those operations include network interactions with many other DOE laboratories, facilities, and vendors. In order to utilize the network, LLNL's infrastructure must provide strong authentication, non-repudiation, message integrity, and privacy for the information being exchanged. An Emergency Access capability is viewed as a critical part of this infrastructure if the full potential of public key encryption technology for privacy is to be realized. LLNL will exercise the Emergency Access capabilities of a commercial software product to ascertain its ability to meet requirements. Point of Contact: Frank Ploof, fploof@llnl.gov

The National Institute of Standards and Technology's (NIST) has responsibility for providing technical support to the other Federal agencies that are participating in the Key Recovery Demonstration Project (KRDP). NIST will issue a Broad Agency Announcement (BAA)that solicits information from vendors about the availability of products, components, and services that can be used in the KRDP. NIST will chair the panel which evaluates responses to the BAA. NIST will also assist the KRDP pilot agencies in the development of their implementation plans. NIST will act as the technical lead for the testing of all pilot Emergency Access systems. NIST will coordinate the development of a comprehensive test suite for each pilot system and assist in evaluating and reporting the test results. In order to establish a pilot public key infrastructure for the KRDP and test the interaction among Certification Authorities (CAs) for the other pilots, NIST will procure and operate a root CA. NIST will also acquire COTS products which provide a secure E-Mail and file encryption capability and permit key recovery. NIST will evaluate and demonstrate the new technology in the NIST Security Division Laboratory. Point of Contact: Jerry Mulvenna, jerry.mulvenna@nist.gov

The National Technical Information Service's (NTIS) FedWorld Secure Web and Certificate Authority Project will prototype trusted-agent services that support digital signature, the encryption of files and messaging, and authorized emergency access to encrypted information through key recovery management. Point of Contact: Mike Williams, mwilliams@fedworld.gov

The Social Security Administration (SSA) and Pitney Bowes Inc. are conducting a proof-of-concept demonstration project with a group of small employers. The project participants securely submit their annual W2/W3 data to SSA over the Internet using public/private key technology. SSA has proposed an expansion of the project to incorporate a test of emergency access to the W2/W3 data. Point of Contact: John Sabo, jtsabo@ssa.gov

The North American Trade Automation Prototype (NATAP): The trilateral Information Exchange and Automation Working Group developed a vision for processing commercial transactions to fulfill the provisions of Article 512 of the North American Free Trade Agreement (NAFTA). The prototype will cover land border transactions: truck and rail. Participants will include Customs, Immigration, Transportation, Census, state and local authorities, and the international trade community. During the prototype, traders and brokers will submit common, standardized, commercial goods and transportation data to the governments (Canada, Mexico, U.S.) in UN/EDIFACT syntax via the Internet using a Trade Software Package (TSP). The governments will perform processing and selectivity functions and return the results of their processing to the trader or broker via the Internet. Transaction related data consists of proprietary information such as trading relationships among sellers and buyers, importers, etc., the prices paid for merchandise, and the declarations made to the governments for the payment (or refund) of import duties, taxes, and fees. This information must be protected against unauthorized access. Accordingly, the TSP must have adequate security through encryption and decryption. (For further info see http://www.itds.treas.gov) Point of Contact: Edward Grose, edward.grose@grosee00.customs.sprint.com

The Patent and Trademark Office's (PTO) International Patent Document Exchange Project will demonstrate the exchange of patent documents in secure electronic form between the Trilateral Offices (U.S. Patent and Trademark Office, European Patent Office, and Japanese Patent Office) and the International Bureau of the World Intellectual Property Office (WIPO) to reduce processing costs and the burden on applicants. Point of Contact: Wesley Gewehr, gewehr@uspto.gov

The Small Business Administration (SBA) Electronic Lending Program is an initiative to re-engineer business loan guarantee processes. The Emergency Access project will feature acceptance of electronic applications for SBA guarantees on FA$TRAK loans from a small group of bank lenders. Point of Contact: Donna Clark, donna.clark@sba.com

The Department of the Treasury, jointly with the GSA Center for Electronic Messaging Technologies, will implement an Electronic Messaging Services Network Infrastructure. This will be comprised of a private Administrative Management Domain for federal government use offering origin authentication, secure access management, data confidentiality, data integrity, non-repudiation, and emergency access. This infrastructure will consist of: SMTP and X.400 email, X.500 directory services, and an Electronic Commerce Clearing House. Point of Contact: Michele Rubenstein, michele.rubenstein@dasis.treas.gov

The further information or if you have any questions about the Key Recovery Demonstration Project, please contact Ms. Patricia N. Edfors, U.S. Department of the Treasury, at (202) 622-1552,patricia.edfors@cio.treas.gov

## Broad Agency Announcement (BAA)

    [Commerce Business Daily: Posted May 29, 1997]
    From the Commerce Business Daily Online via GPO Access
    [cbdnet.access.gpo.gov]

    PART: U.S. GOVERNMENT PROCUREMENTS
    SUBPART: SUPPLIES, EQUIPMENT AND MATERIAL
    CLASSCOD: 70--General-Purpose Information Technology Equipment
    OFFADD: National Institute of Standards & Technology, Acquisition
      & Assistance Div., Bldg. 301, Rm B117, Gaithersburg, MD 20899
    SUBJECT: 70--SUPPORT DATA ENCRYPTION IN FEDERAL GOVERNMENT APPLICATIONS
    SOL 52SBNB7C1208
    DUE 071197
    POC Marsha Rodgers (301)975-6398, FAX (301)963-7732
    DESC: BROAD AGENCY ANNOUNCEMENT -- The National Institute of
      Standards and Technology (NIST) is soliciting proposals for
      products and services which will demonstrate the viability
      of the recovery of keys that are used to support data encryption
      in Federal government applications. BACKGROUND: In May 1996,
      the Office of Management and Budget (OMB) released a white
      paper entitled "Enabling Privacy, Commerce, Security, and Public
      Safety in the Global Information Infrastructure". This paper
      stated that "government and industry must work together to
      create a security management infrastructure and attendant products
      that incorporate robust cryptography without undermining national
      security and public safety". Recently, a task group was formed
      for the purpose of testing the feasibility of implementing
      emergency key recovery capabilities in Federal Government applications.
      Approximately ten Federal agencies will participate in a Key
      Recovery Demonstration Project (KRDP), formerly known as the
      Emergency Access Demonstration Project (EADP) , to demonstrate
      the viability of key recovery. In this Broad Agency Announcement
      (BAA), NIST is soliciting products and services to support
      this project. GOALS: Specific goals of the KRDP include the
      following : (a) demonstrate the practicality of key recovery
      in Federal Government applications; (b) determine to what extent
      Commercial Off-The-Shelf ( COTS) products or commercially available
      services currently exist to support key recovery. Products
      that can be modified with minimum difficulty will also be considered;
      (c) determine how these products and services can be integrated
      into existing applications; (d) identify, implement, test and
      evaluate diverse key recovery technologies; and (e) identify
      barriers to interoperability among applications that use different
      key recovery technologies and make recommendations for lessening
      or removing those barriers. OBJECTIVES: Different methods of
      key recovery will be demonstrated . Encryption keys will be
      recovered by Key Recovery Agents upon receipt of an authorized
      request; keys used for digital signatures will not be recovered.
      Off-the-shelf technology is being sought for use on this project;
      there are no restrictions on standards compliance or algorithm
      usage. The KRDP will include a Public Key Infrastructure (PKI)
      which consists of a root Certification Authority (CA) and several
      dependent Certification Authorities. CAs certify the public
      keys of particular user communities and provide certification
      paths to other CAs so that public keys in other CA domains
      may be verified. The root CA will be located at and be operated
      by NIST. The remaining CAs will be located either at the sites
      of agencies participating in the project or at third party
      sites. Other components of the KRDP that will be procured under
      this BAA include Organization Registration Authorities (ORAs)
      and Key Recovery Agents (KRAs). ORAs authenticate users, validate
      requests, and interact with the Certification Authorities;
      ORAs may also request key recovery from a KRA. KRAs are used
      to recover keys, key components or plaintext messages upon
      the receipt of an authorized request. The infrastructure imposes
      no implementation constraints. An example of the services provided
      by a CA and a KRA could be included in a single product. An
      example infrastructure which illustrates three possible methods
      for accomplishing key recovery in a PKI environment can be
      found at the web site specified in this BAA. PROPOSAL CONTENT:
      NIST is seeking the following information about off-the-shelf
      products and/or services that can be used in the Key Recovery
      Demonstration Project: the functionality of the product or
      service (e.g., CA, ORA, KA, user); whether a product or a service
      is being offered; a list of all features (e.g., key generation)
      provided by the product or service; a description of the proposed
      key recovery methodology to be used, if appropriate; whether
      the proposed product or service is currently available and,
      if not, the expected date of availability; the requirements
      for operating or communicating with the proposed product or
      service; information which specifies how the product or service
      can be integrated with the product(s) and service(s) provided
      by other vendors or with other project elements (e.g., CA,
      ORA), if applicable; any constraints on product integration,
      such as dependence on a particular cryptographic algorithm,
      cryptographic product, communication interface etc.; and the
      extent to which additional negotiated enhancements to the product
      and/or service can be made . Since the enhancements that may
      be requested cannot be specified at this time, a general statement
      about the capability of responding to such a request is all
      that is required. The following information about the KRDP
      elements should be provided when being proposed by a vendor:
      (1) Certification Authority - A Certification Authority system
      certifies public keys and optionally generates public/private
      key pairs and may act as a certificate repository. If a Certification
      Authority system is provided as a service, specify the services
      provided and the cost of each service. Explain any factors
      that will cause the cost to vary and the method of obtaining
      the services that are provided. If a Certification Authority
      can be purchased, explain the impact of any factors that will
      affect the initial procurement cost and provide the cost of
      operating the system.Vendors who provide only a certificate
      repository service should specify the cost and the method of
      accessing this service . (2) Key Recovery Agent - If key recovery
      is provided as a service, specify the cost of registering with
      the key recovery service and the costs of key recovery operations.
      Indicate how these costs will vary, depending upon the number
      of users that are registered and the number of key recoveries
      that are performed. Specify the key archival services provided,
      if applicable, and the cost of these services. List and specify
      the costs of cryptographic products that must be used in conjunction
      with the key recovery service. If a key recovery product can
      be procured for operation by the user or user's representative,
      list all factors that will affect pricing. List and specify
      the costs of cryptographic products that must be used in conjunction
      with the key recovery service. (3) Organization Registration
      Authority - Specify all costs associated with the procurement
      and operation of an Organization Registration Authority. Explain
      the method of interaction with the Certification Authority
      and the Key Recovery Agent,wherever applicable. (4) User Software
      - Specify the functionality and cost of all user software that
      is required to perform encryption/decryption, key generation,
      key recovery, certificate path acquisition and verification
      and to interact with other system elements (e.g., Certification
      Authority, Key Recovery Agent). Responders should also provide
      any additional information about the functional capabilities,
      performance and cost of their product or service that will
      assist Federal agencies participating in the Key Recovery Demonstration
      Project in evaluating the offerings. Where cryptographic functions
      are performed, responders should state the degree to which
      their offered product or service complies with FIPS 140-1 .
      Where applicable, responders should specify the degree to which
      their offered product or service complies with the NIST draft
      " Minimum Interoperability Specification for PKI Components".
      SUBMISSIONS - Offerors are encouraged to submit concise, but
      descriptive proposals which will be accepted until 5:00 P.
      M., EST on JULY 11, 1997. Five (5) copies of the proposal shall
      be submitted to the following address: Marsha Rodgers, Acquisition
      and Assistance Division, National Institute of Standards and
      Technology, Building 301 Room B117, Gaithersburg, Maryland
      20899. PROPOSALS SENT BY FAX OR E-MAIL WILL BE REJECTED. Proposals
      will be selected through a technical/scientific/business decision
      process with technical and scientific considerations being
      most important. Individual proposal evaluations will be based
      on acceptability or nonacceptability without regard to other
      proposals submitted under the announcement. HOWEVER, DUE TO
      BUDGETARY CONSTRAINTS, ALL ACCEPTABLE PROPOSALS MAY NOT BE
      FUNDED. No award will be made without a proposal to perform
      the specific effort within an estimated cost and time framework.
      PROPOSAL FORMAT- Proposals shall consist of two separate parts.
      Part 1 shall provide the technical proposal and Part 2 shall
      address costs. The proposal must not exceed the number of pages
      stated below (a "page" is defined to be a sheet of paper no
      greater than 8 x 11 inches, in type not smaller than 12 pitch)
      . Part 1 shall include: (1) Cover Page (1 Page) (a) Title:
      Key Recovery Demonstration Project Proposal; (b) Name of organization
      submitting proposal; (c) Contracting Official (Name, Title,
      Address, Telephone Number, Electronic Mail Address); (d) Technical
      Contact (Name, Title, Address, Telephone Number, Electronic
      Mail Address); (2) Organization Description (1 page)- (a) Principal
      business of organization; (b) Major qualifications and past
      achievements in data encryption/key recovery technology;(c)
      KRDP system elements for which proposal is being submitted.(3)
      Offered Products and/or Services (1-3 pages per offered product
      or service) - For each offered product and/or service, responders
      should provide the corresponding information requested in the
      Proposal Content Section of this BAA. Part 2, Costs, shall
      be supported by detailed breakdowns of labor hours by labor
      category and tasks/subtasks, materials, travel, computer and
      other direct and indirect costs. ADDITIONAL INFORMATION: The
      following documents can be accessed at World Wide Web site
      http://csrc.nist.gov/krdp: KRDP Project Summary, FIPS - 140-1,
      Implementation Evaluation Criteria for the KRDP, "Enabling
      Privacy, Commerce, Security, and Public Safety in the Global
      Information Infrastructure", referenced on Page 1, draft Minimum
      Operability Specification for PKI Compontents, and example
      Methods of Key Recovery. Any further technical questions relating
      to the BAA should be directed to : Jerry Mulvenna, Phone -
      (301) 975-3631, E-Mail Address - jerry.mulvenna@nist.gov. Any
      contractual questions should be directed to Marsha Rodgers
      at (301)975-6398. The period of performance of the BAA is six
      months from the date of each award. This announcement constitutes
      a Broad Agency Announcement as contemplated in FAR 6.102(d)(2).
      There will be no formal request for proposals or other solicitations
      regarding this announcement. Proposals shall be valid for a
      periodof twelve (12) months after submission. Where the effort
      consists of multiple portions which could reasonably be partitioned
      for purposes of funding, these should be identified with separate
      cost estimates for each. The Government reserves the right
      to select for award any, all, part, or none of the proposals
      received in response to this announcement. This BAA is an expression
      of interest only, and does not commit the Government to pay
      any pre-proposal or proposal preparation costs. All responsible
      sources may submit a proposal which shall be considered. EVALUATION
      CRITERIA/AWARD PROCESS : Proposals will be evaluated based
      on acceptability or unacceptability using the following criteria
      which are listed in decreasing order of priority: (1) Utility
      for Meeting Project Goals - For data recovery systems, the
      offered products and/or services should provide a method of
      implementing key recovery in Federal Government applications
      or the means to be integrated with the products and services
      offered by other contractors to provide this service. Reference
      the Implementation Evaluation Criteria for the KRDP at the
      above-mentioned web site. (2) Availability of Offered Products
      and/or Services - The offered products or services should be
      able to be integrated within a timeframe that will allow testing
      to commence as soon as possible.(3) Compliance with Applicable
      Standard or Specification- Where applicable, the degree to
      which the offered product or service complies with FIPS 140-1
      or the draft "Minimum Interoperability Specification for PKI
      Components" shall be considered a positive factor in the proposal
      evaluation.(4)Diversity of Key Recovery Solutions- A primary
      project goal is to implement, demonstrate and evaluate different
      solutions for key recovery. Accordingly, products and/or services
      providing differing solutions will be preferred.(5) Past Performance
      - the offeror's capabilities, related experience, facilities,
      techniques, or unique combinations thereof which are integral
      factors for achieving the proposed objectives; and (6) Cost
      and cost realism - Cost realism will be used only as an evaluation
      criterion in proposals which have significantly under-or-over-estimated
      the cost to complete their effort. All awards made in response
      to this BAA shall be subject to availability of Government
      funds. Proposals will be evaluated and ranked by a Source Selection
      Evaluation Panel (SSEP) composed of representatives of Federal
      Agencies participating in the KRDP.
    LINKURL: http://www.nist.gov/admin/od/contract/contract.htm
    LINKDESC: NIST Contracts Homepage
    EMAILADD: Contract@nist.gov
    EMAILDESC: NIST Contracts Office
    CITE: (W-149 SN078311)

## Key Recovery Examples

The Key Recovery Demonstration Project (KRDP) will include a Public Key Infrastructure (PKI) which consists of a root Certification Authority and several dependent Certification Authorities. The following figure shows an example infrastrucrture which illustrates three possible methods for accomplishing key recovery in a PKI environment. CAs certify the public keys of particular user communities and provide certification paths to other CAs so that public keys in other CA domains may be verified. Organization Registration Authorities (ORAs) authenticate users, validate requests, and interact with the Certification Authorities; ORAs may also request key recovery from a Key Recovery Agent (KRA). Key Recovery Agents are used to recover keys, key components, or plaintext messages upon the receipt of an authorized request. The infrastructure imposes no implementation constraints. For example, the services provided by a CA and a KRA could be included in a single product.

In method A of the example infrastructure, a key has been stored and is directly accessible by the Key Recovery Agent. In method B, key components have been stored at separate storage locations from which they may be retrieved. In method C, the Key Recovery Agent does not need to store the user's key. For example, a message header could contain a session key that has been encrypted with a key known by the Key Recovery Agent. Although the figure shows the key recovery services as being provided by a remote entity, these services can be colocated with any of the elements shown on the figure (e.g., ORA, user).

## KRDP Implementation Evaluation Criteria

### 1. Objective

The objective of the Key Recovery Demonstration Project is to demonstrate the feasibility of emergency access to encrypted information in order to meet federal requirements for continuity of business, public safety, and national security interests. The demonstration project will examine various techniques for emergency access using varied technical approaches to encourage creativity in developing these capabilities. The demonstration project will not access digital signatures and, consequently, will encourage capabilities that use separate keys for digital signature and confidentiality. The choice of terms used in this list of criteria is intended to allow for this variety. The purpose of this evaluation criteria is to provide a disciplined approach to identifying and addressing the functional and security concerns related to the federal government's needs for emergency access to encrypted data. The criteria will serve as the basis for testing emergency access systems of pilot applications. The demonstration project members will enhance these criteria to meet the needs of each pilot application. However, the criteria presented below will serve as the minimum core criteria. Rationale for the enhancement of the criteria will be part of the business and cost/benefit analyses conducted for each pilot.

### 2. Glossary

A. Authorized requester(s) is that individual or entity permitted to obtain a key and/or key component under conditions specified pursuant to proper, lawful authorization.

B. Data is specific individual facts or a list of such items; facts from which conclusions can be drawn; any or all facts, numbers, letters, symbols, etc. that can be processed or produced by a computer.

C. Emergency access - acquisition of the plaintext information associated with ciphertext for which the decrypting key is not readily available.

D. Emergency access system (EAS) - includes the policies, procedures, and all emergency access components required to recover encrypted data.

E. Key - a parameter that determines the transformation from plaintext to ciphertext and/or vice versa.

F. Key component - one of at least two parameters having the format of a key that is combined with one or more like parameters to form a key

G. Key encryption key - a key used exclusively to encrypt and decrypt keys.

H. Key Recovery Agent - company, individual and/or entity that runs an Emergency Access System.

I. Key Recovery Center - location from which keys are obtained, for the purpose of emergency access.

J. Owner of the data - to be determined for each pilot.

K. Session, as in session data, is a logical connection between two terminals; part of a message transmission when two parties are exchanging messages; that which takes place after a communications circuit has been set up and is functioning, and which ends when the circuit has been terminated.

### 3. Evaluation criteria for an emergency access system (EAS).

A. An EAS shall implement policies, procedures, and mechanisms to ensure the confidentiality, integrity, and availability of the EAS and the information it processes, stores, audits and transmits.

B. The EAS shall implement procedures to recover from compromise of the confidentiality, integrity or availability of the EAS, subsystems, and keys and/or key components.

C. It should not be possible for an unauthorized person or process to alter, disable, bypass or corrupt an EAS, its subsystems or its components.

D. An EAS shall be designed and operated so that a failure by a single person, procedure, or mechanism does not compromise the confidentiality, integrity or availability of keys and/or key components or the EAS itself.

E. Unencrypted keys and/or key components shall be protected against modification, deletion and unauthorized disclosure while in storage, transmission or transfer.

F. The EAS shall ensure that each key recovery center (KRC) is uniquely identified. Encrypted data shall be bound to (associated with) the unique identity of the KRC and other information which is sufficient for the emergency access system to recover the encrypted data. This information shall be in an accessible format and occur with reasonable frequency to provide emergency access.

G. An EAS shall ensure emergency access to encrypted data without inducing errors, and without intruding upon or disrupting data system and/or storage service.

H. An EAS shall maintain data relating to emergency access events in sufficient detail for auditing by authorized officials or their representatives.

I. An EAS shall ensure that only the requested key and/or key component(s) shall be provided.

J. An EAS shall ensure that the decrypted data, and the key and/or key component(s) are obtainable in a timeframe reasonable to support federal government business operations.

K. An EAS shall enforce the start and end of a time interval for authorized access to stored data, session data, and/or multiple sessions of data.

L. In response to a proper, lawful authorization, an EAS shall be capable of providing more than one key and/or key component at once or over the authorized time interval, if appropriate.

M. An EAS shall be capable of providing the key and/or key component needed to decrypt the data regardless of whether the sender's or receiver's cryptographic product generated or received the ciphertext.

N. The EAS shall ensure that key and/or key components are provided only after authenticating the identity and authority of the requester, and in response to established mechanisms and/or procedures pursuant to proper, lawful authorization.

O. The EAS shall disclose keys and/or key components only to authorized requester(s).

P. The EAS shall ensure access to keys and/or key components for the life of the encrypted data. In addition, in the event an EAS subsystem or component dissolves or otherwise terminates emergency access operations, the emergency access capability shall be transferred to another EAS that meets the federal client's performance and security requirements.

Q. The EAS shall protect against disclosure of information to unauthorized entities regarding the identity of the person and/or organization whose key and/or key component(s) is requested, the fact that a key and/or key component was requested or provided, and the identity of the requester.

R. The Key Recovery Agent shall be a federal department or agency, or a U.S. registered company(ies), or through a U.S. treaty relationship.

S. The EAS operating procedures shall designate an individual(s) responsible as security and operations officer(s); all EAS shall designate individual(s) responsible for the security and the operations of their subsystems.

T. Non-Government entities performing EAS functions shall possess suitable evidence of corporate viability, e.g., a Certificate of Good Standing for the State of Incorporation, appropriate business registration documents, a credit report, errors and omission insurance coverage.

U. The entities performing EAS functions shall certify compliance with all applicable federal, state, and local laws and regulations.

V. The EAS serving the U.S. Government business shall interoperate only with EAS that meet these criteria.