[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: My chat with Goeff Greiveldinger
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 officials�and 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 | [email protected]
P.O. Box 248087 | http://www.law.miami.edu/~froomkin
Coral Gables, FL 33124 USA | It's hot here. And humid.