Friday's NIST Key Escrow FIPS Workshop

[Thomas Grant Edwards <tedwards@Glue.umd.edu>]

I went to the NIST "Developing Key Escrow Encryption Standards Workshop" 
held in Gaithersburg, MD on Sept. 15, 1995.  It turns out I know the guy
who was running the conference so I knew I couldn't miss it...and I knew I
had to wear my Cypherpunks t-shirt to show the flag (and it stood out, as
there were few without suits there). I got to meet Dorothy Denning for the
first time.  I was mentioning how government key-escrow doesn't sound too
bad to some in the libertarian/cypherpunk world, say for instance to
ensure FOIA requests are not encrypted away.  She said that would never be
a problem, just getting the government to give you FOIA documents in the
first place is the problem. 

In a nutshell, this was a conference to begin work on a FIPS for software 
key encryption escrow.  Industry people there felt that a FIPS would be a 
great way to standardize key escrow for data recovery.  However, except 
for one guy at IBM who said they tap employees phones alot, most industry 
people felt that it was not needed for tapping their real-time 
communications.  There was a lot of talk from government people about the 
need for Law Enforcement to get access to encrypted real-time 
communication between government employees.  This, to say the least, 
squicked many attendees, and there seemed to be much tension between the 
sides on that issue.

I asked a couple of industry people and privacy advocates the question "Am
I just paranoid, or is this FIPS a trial balloon for mandated civillian
key escrow?"  I got many "yes" answers.  I also heard the occasional "this
sounds like son-of-clipper" comments in the breakout groups. 

One noteworthy point is that RSA sent in a position paper to try to get 
the Digital Signature Standard replaced by RSA signatures for inclusion 
in key escrow FIPS due to its "virtual non-availability in commercial 
products," and noted that the US Govt. has free use of RSA sigs.

Another noteworthy point is that NIST made clear that the key escrow FIPS 
should _not_ involve SECRET algorithms.  

The Workshop consisted of a discussion of goals and objectives by Ray
Kammer (Deputy Director, NIST) and some initial thoughts on standards
development by Miles Smid (NIST).  Here is the gist of the overhead
slides: 

The Goals of the workshop were based on the August 17 announcement by the
Administration to allow for exportability of 64-bit software key escrow
encryption, plans to allow Federal agencies to use Escrowed Encryption
Standards compliant hardware devices for data communications, and the
development of a FIPS for key escrow, implementable in software.  This
escrow FIPS would be used by Federal agencies in conjunction with
FIPS-approved encryption techniques.  This workshop was held to help 
begin the FIPS development.  The workshop goals included 1) Providing 
input to the govt. on drafting a software key escrow encryption standard; 
2) Helping govt. to identify additional policy and technical issues that 
need to be addressed and 3) providing the govt. with thoughts on drafting 
and follow-up

The FIPS process involves developing the draft FIPS, a 90 day comment 
period, then addressing comments, and then it goes to the Secretary of 
Commerce for signature, and becomes effective six months after the 
signature.  

The purpose of the New Escrow FIPS is to foster a wider use of escrow 
technology...this means: no requirement for SECRET algorithms, software 
and hardware implementations, and exportability.  It also will provide a 
government validation of escrow systems meeting the 
standard...theoretically allowing for security, integrity, and availability.

Threats examined included compromise (unauthorized disclosure of keys and 
data recovery), and denial of service (modification or loss of keys, use 
of bogus recovery fields, and improper system operation).

The FIPS will provide common formats and procedures which will facilitate 
data recovery and lower cost.  Applicability of the FIPS will include the 
US Govt. and contractors.  Applications include both stored and 
transmitted data.  Encryption algorithms must be FIPS approved.  And 
finally desirable features include: auditing, configuration control, 
backup capability, and efficiency.

The questions asked to the breakout groups included:

1) Is a standard interface for the release of keys desirable?
2) What documentation is required?
3) How will operational procedures be developed?
4) How will conformance be validated?
5) Will security be evaluated?  If so, under what criteria and by whom?
6) How will configuration control be maintained?
7) Are new FIPS-approved algorithms necessary?
8) Should escrowing be built into the Public Key Infracstructure?
9) Is a standard escrow system identification field needed?
10) Is split knowledge required?
11) Do systems which permit data to be encrypted for both storage and 
transmission need to provide for both kinds of escrow?
12) Does the government require special features (2-hour access, 
continuous real-time decryption, etc.)?