From: Michael Froomkin <froomkin@law.miami.edu>
Date: Tue, 17 Oct 95 17:45:15 PDT
To: cypherpunks <cypherpunks@toad.com>
Subject: Re: My chat with Goeff Greiveldinger
In-Reply-To: <9510171621.AA12393@tis.com>
Message-ID: <Pine.SUN.3.91.951017203951.13039C@viper.law.miami.edu>
MIME-Version: 1.0
Content-Type: text/plain


Here is my first cut at what I plan to say.   Not real exciting, but I 
don't know how much knowledge to assume in the audience.

I would be grateful for a pointer to any commercial key escrow services 
that are actually in operation today.  And doubly grateful for a pointer 
to one that does not rely on a proprietary encryption scheme and/or one 
that allows/requires key splitting for extra security.

Key Escrow in Secure Electronic Commerce 
October 19, 1995 4:30 pm - 5:50 pm 

Outline

Intro:
In this talk I will...
     *    Begin with why business wants/needs *data* CKE
     *    Turn then to law enforcement focus on communications KE
     *    Explain how govt hardball on export control in pursuit
          of Comm KE threatens needed CKE -- or at least US
          companies' share of that market...
     *    Discuss pending issues

I.   Commercial key escrow, the WHAT, WHY, WHO and HOW

     A.   WHAT 
     Give someone (internal/external) copies of keys (private/
     symmetric) used in the course of business
          1.   Essential (from corporate perspective) for
               a.   all encrypted, stored corporate data
               b.   keys with power
                    (1)  to sign things in corporate name e.g.
                         buy/sell
                    (2)  to issue certificates

          2.   Less essential (from corporate perspective)
               a.   for email keys
                    but still pretty important if you might have
                    to reconstruct exchanges of messages at a
                    later date.
               b.   for telephone keys
                    although useful if you think there will be
                    need for you and/or police to spy on your
                    employees, eg. investigate fraud/theft.

     B.   WHY
          1.   Irresponsible for corporation not to encrypt data
               and some communications if these are of commercial
               value to competitors/otherwise sensitive
          2.   Irresponsible to encrypt data (and maybe also
               communications) and not have fail-safe means of
               access
               a.   employees lose their keys
               b.   employees die
               c.   employees quit (and vanish or do some vandalism)
               d.   employees are suspected of engaging in hanky-
                    panky

     C.   WHO
          Escrow agent could be 
          1.   internal
               a.   only viable solution right now unless you are
                    satisfied with, e.g., RSA non-interoperable
                    crypto system
               b.   but are you hacker-proof?

          2.   external, e.g.
               a.   TIS licensed "Data Recovery Center" (but
                    there are none in existence today)
               b.   bankerstrust
               c.   govt agency (someday? but not today)
               d.   can use split key systems for increased
                    security. [but is anyone actually offering such a 
                    service?]

          One problem with external is that NONE of the liability
          issues are resolved.  E.G.  Suppose private escrow
          agent complies in good faith with facially valid
          warrant, but warrant is l

     D.   HOW
          Here we have more doubts than knowledge
          Not clear yet what security precautions commercial
          escrow agents will offer.  Can assume:
          1.   Secure systems
          2.   Contract-driven mechanism for verifying IDs/bona
               fides of persons attempting to take out data
          3.   Contract-driven assurances of speed of response
          4.   split key systems with different escrow agents?


II.  Legal implications of commercial key escrow

     Three families of issues: 
          1.   data owner liability for not escrowing
          2.   escrow agent liability for errors
          3.   Government access to keys

     A.   It is irresponsible NOT to escrow keys if you encrypt
          data.  And it is increasingly irresponsible not to
          encrypt.  Hence some form of escrow will become
          practically mandatory.
          1.   Query: won't this make it easier for the
               government to get access to my data?  

               Answer: must distinguish between stored data and
               communications.   You are escrowing the keys not
               the data itself.  The data remains secure in your
               own machine/tape/safe/whatever.  There it's
               subject to subpoena just like paper records.  So
               encryption + escrow is no substitute for
               destroying the smoking gun, but it's also no more
               danger than ordinary records.

               Escrowing keys used for communication makes those
               communications more vulnerable to government
               interceptions.  Strong, unescrowed, keys may
               defeat even a lawful subpoena for a wiretap. 
               Escrowed keys are vulnerable to legal (at least)
               wiretaps.  

          2.   More on "practically mandatory":  The government
               may make it a condition of doing certain kinds of
               business, e.g. govt contracting, that only
               escrowed encryption be used.   Similarly, the
               government may be willing to engage in secure
               communications with the public, but only via
               system that are limited to escrowed keys.

          3.   Still more on "practically mandatory": carrot &
               stick of export controls (see below).

     B.   Escrow agent liability for errors

          Currently, rights and resp of customer vs. escrow
          agents depend on whether escrow agent is public or
          private

          1.   Public escrow agent -- low accountability?

     In the "Clipper 1" proposals, the escrow system lacked any
legal guarantees for the people whose keys are generated by the
government and held by the escrow agents.  Indeed, the Attorney
General's escrow procedures stated that they 
     do not create, and are not intended to create, any
     substantive rights for individuals intercepted through
     electronic surveillance.  
In short, the government disclaimed in advance any reliance
interest that a user of an EES-equipped device might have in the
government's promise to keep the key secret.  A victim of an
illegal wiretap would have a cause of action under Title III
against the wiretapper, but, it appears, no remedy against the
escrow agents, even if the escrow agents acted negligently or
failed to follow their own procedures.  The Attorney General's
procedures themselves are merely directives.  They are not even
legislative rules, which might be subject to notice and comment
restrictions before being rescinded.  A future administration
could, if it wanted, secretly instruct the escrow agents to
deliver copies of the keys to an intelligence or law enforcement
agency, or even White House plumbers, thereby violating no law
or regulation (the plumbers, though, would violate Title III when
they used the information).  Because the chip-unique keys were
voluntarily disclosed to the government, the chip's owner might
lack a legitimate (that is, enforceable) expectation of privacy
in the information. 

     If the intercepted communication were an e-mail or a file
transfer, rather than a telephone call, the chip owner subject to
an illegal or inadvertent disclosure by the escrow agents may be
in a particularly weak position if the information ever makes its
way to court:  many Title III protections granted to voice
communications do not apply to transfers of digitized data.

     Shortly before the 103d Congress adjourned, Congressman
George Brown introduced the Encryption Standards and Procedures
Act of 1994, which would have waived the sovereign immunity of
the United States for willful but unauthorized disclosures of
key fragments by its officialsand excluded liability in all
other circumstances.  In the absence of similar legislation,
however, there may currently be no monetary remedy even for a
willful disclosure.

          2.   Private escrow agent -- contract accountability,
               tort, maybe bailee/trustee (dubious)

     If you want software key escrow today, you have to be your
own escrow agent, or go to a private escrow agent because there
is no government agency ready and able to act in this capacity
(and few private bodies!)  Given current liability rules, you
would be better off with a private body than the government
anyway (tradeoff: maybe more security in government agency (?)
vs. more recourse against private party).

     The "son of clipper" trial balloon floated this fall
suggested that export permission would be given to (relatively)
strong (ie. 64 bit max) software cryptosystems, if those systems
were designed to ensure that the keys were escrowed with an
"approved escrow agent".  NIST solicited comments in Sept. '95 as
to 
               a.   what sort of bodies would be suitable, and 
               b.   what terms and conditions should govern the
                    escrow agents.  
               c.   What procedures need to be developed for the
                    storage and safeguarding of keys?
               d.   Performance criteria (e.g., around-the-clock
                    availability, accessibility, reliability,
                    etc.) for approved key escrow agents?
               e.   Under what circumstances will key escrow
                    agents in foreign countries be approved?
               f.   Should approval of key escrow agents be tied
                    to a public key infrastructure (for digital
                    signatures and other purposes)?  
     [The last point is potentially ominous...if access to
     digital signature infrastructure is conditions on using KE,
     then this makes export control hardball look like small
     beer]

     To date there has been no public feedback from NIST
subsequent to the meeting except that they are revising the
criteria in light of what they heard.  [Can GG tell us more?]


     C.   Government access to keys

          NB that government seems primarily interested in
communications; business main focus is/should be DATA.

     Now with "Son of Clipper" (software KE), the government has
relaxed the suggestion that keys be generated and escrowed via
hardware (e.g. Fortezza), but has substituted onerous criteria it
hopes it can persuade (threaten?) industry to apply to software,
including:


III. (Mostly specious) Arguments Against Commercial Key Escrow
[with apologies to Marc Rotenberg, Electronic Privacy Information
Center, who posted the quoted material to USENET several months
ago]

     A.   Bad for business
          1.   "Increased network vulnerability.  The key escrow
               configuration necessarily increases the likelihood
               of communications compromise and improper
               interception by third parties. Computer crime will
               skyrocket."

               Very unrealistic and alarmist.  While as a
               theoretical matter it is clearly true that the
               sharing the keys with the escrow agent must create
               an avenue of attack that did not exist before, the
               risk can be very greatly reduced by 
               a.   key splitting (never send the whole key to
                    anyone at any time)
               b.   secure communications with very secure
                    algorithms between escrow agent and customer
                    [NB that US government export policy
                    implicates this to the extent it makes strong
                    crypto non-exportable]

          2.   "Policy incoherence.  The key management needs of
               business differ sharply from the real-time
               intercept plans of law enforcement. The latter has
               little to do with the former."

               Probably true, but irrelevant to the matter at
               hand: business needs escrowing for its own
               disaster recovery needs.

          3.   "Complexity.  Has anyone really given thought to
               how many communications will be encrypted in 20
               years and what the key management requirements
               will be to develop a unitary key escrow system to
               satisfy the government's concerns?"

               Maybe, maybe not.  But businesses need CKE now. 
               Keys don't live for ever, and a sound security
               plan will include provisions for retiring keys as
               they age.  Age makes keys vulnerable
               a.   technological change makes bruting longer
                    keys possible
               b.   the longer the key is out there the more time
                    attackers have to brute (or otherwise
                    compromise) the key

     B.   Bad for civil liberties

          1.   "Emergency circumstances taps.  The current
               wiretap law permits the initiation of a wiretap
               *without court order* upon a certification that
               emergency circumstances exist. If this procedure
               is built into the CKE procedure, then there will
               be *no judicial review* prior to the disclosure of
               keys."

               True.  But these taps are currently rare, and
               limited to cases like kidnapping where lives are
               at stake.  It's fairly unlikely that a business
               will ever encounter one of these.


          2.   "The future of PGP.  Will PGP and other non-escrow
               schemes be permitted if CKE is adopted? What will
               be the implications for developers and companies
               in the communications industry?"

               Voluntary CKE in and of itself is not going to
               affect the legality of alternative un-escrowed
               crypto.  The politics are hard to predict: one can
               imagine arguments that mandatory escrow is not
               needed because it's being done voluntarily; and
               also arguments that the increasing voluntary CKE
               means that there's less reason not to make it
               mandatory.   My guess: no great effect one way or
               the other.  The issue will be settled by larger
               things e.g. what's more scary -- Oklahoma City or
               Ruby Ridge?

IV.  Recent Developments in key escrow

     A.   NIST initiatives

          NIST is currently putting "final touches" on draft
          export criteria, under auspices of inter-agency working
          group. NIST hopes to "notice" revised draft criteria in
          fed register, perhaps within the next month; then a
          60day comment period, with a 1-day live meeting in DC
          sometime during the comment period.


          When NIST has final version of inter-agency
          recommendations set, they will be turned over to the
          state dept to implement; state can do what it likes. 
          One possible model for State Dept. action is a change
          to the ITAR.

V.   Outstanding Issues
     A.   Why would any foreign company use US govt approved
          crypto in light of new focus on economic intelligence,
          e.g. Japan spy case?
          Possible govt responses:
          1.   foreign govt might have copy of key?  share key?
          2.   foreign-based, but US-approved, escrow agent might
               hold/share key

     B.   MANDATORY CKE?
          1.   Legislation?
          2.   "milder variants"
               a.   export control club (is 64 bits enough?)
               b.   data vs. communications issue
               c.   Digital signature infrastructure access club
                    (informal talks suggest this is not likely,
                    but not formally ruled out....)

     C.   Enabling ("technical") legislation
          1.   Title III exemption for escrow agent
          2.   Authority to "certify" escrow agents
          3.   liability rules for escrow agents

     D.   Enabling regulations
          1.   Care & feeding of escrow agents, 
               a.   eg. sample criteria for being approved and/or
                    sample contract between government and escrow
                    agent
               b.   performance criteria for escrow agents e.g.
                    response time

     E.   Liability in the absence of legislation
          1.   First, find someone actually selling escrow
               services with an interoperable product.
          2.   Or, resign yourself to eg RSA keys.

A. Michael Froomkin        | +1 (305) 284-4285; +1 (305) 284-6506 (fax)
Associate Professor of Law | 
U. Miami School of Law     | froomkin@law.miami.edu
P.O. Box 248087            | http://www.law.miami.edu/~froomkin
Coral Gables, FL 33124 USA | It's hot here.  And humid.