New Threat on the Horizon: Software Key Escrow

At the June Cypherpunks meeting, Whit Diffie (co-inventor of
public-key crypto, as you should all know) filled us in on a workshop
on "key escrow" held in Karlsruhe, Germany. All the usual suspects
were there, and I gather that part of the purpose was to bring the
Europeans "into the tent" on key escrow, to deal with their objections
to Clipper, and so on.

Diffie described in some detail a software-based scheme developed by
NIST (and Dorothy Denning, if I recall correctly) that, as I recall
the details, avoids public key methods. Perhaps this was also
described here on the list. I know Bill Stewart has recently discussed
it in sci.crypt or talk.politics.crypto.

What has me worried about it now is evidence from more than one source
that this program is actually much further along than being merely a
"trial balloon" being floated. In fact, it now looks as though the
hardware-based key escrow systems will be deemphasized, as Al Gore's
letter seems to say, in favor of software-based schemes.

While I've been skeptical that software-based schemes are secure (the
bits are hardly secure against tampering), the addition of negotiation
with another site (a lot like online clearing of digital cash, it
seems) can make it nearly impossible for tampering to occur. That is,
I'm now more persuaded that the NIST/NSA(?) proposal would allow
software-based key escrow.

Here's the rub:

* Suppose the various software vendors are "incentivized" to include
this in upcoming releases. For example, in 30 million copies of
Microsoft's "Chicago" (Windows 4.0) that will hit the streets early in
'95 (betas are being used today by many).

* This solves the "infrastructure" or "fax effect" problem--key escrow
gets widely deployed, in a way that Clipper was apparently never going
to be (did any of you know _anybody_ planning to buy a "Surety"
phone?).

(Granted, this is key escrow for computers, not for voice
communication. More on this later.)

* Once widely deployed, with not talk of the government holding the
keys, then eventual "mandatory key escrow" can be proposed, passed
into law by Executive Order (Emergency Order, Presidential Directive,
whatever your paranoia supports), an act of Congress, etc.

I don't claim this scenario is a sure thing, or that it can't be
stopped. But if in fact a "software key escrow" system is in the
works, and is more than just a "trial balloon," then we as Cypherpunks
should begin to "do our thing," the thing we've actually done pretty
well in the past. To wit: examine the implications, talk to the
lobbyist groups about what it means, plan sabotage efforts (sabotage
of public opinion, not planting bugs in the Chicago code!), and
develop ways to make sure that a voluntary key escrow system could
never be made mandatory.

(Why would _anyone_ ever use a voluntary key escrow system? Lots of
reasons, which is why I don't condemn key escrow automatically.
Partners in a business may want access under the right circumstances
to files. Corporations may want corporate encryption accessible under
emergencyy circumstances (e.g., Accounting and Legal are escrow
agencies). And individuals who forget their keys--which happens all
the time--may want the emergency option of asking their friends who
agreed to hold the key escrow stuff to help them. Lots of other
reasons. And lots of chances for abuse, independent of mandatory key escrow.)

But there are extreme dangers in having the infrastructure of a
software key escrow system widely deployed.

I can't see how a widely-deployed (e.g., all copies of Chicago, etc.)
"voluntary key escrow" system would remain voluntary for long. It
looks to me that the strategy is to get the infrastructure widely
deployed with no mention of a government role, and then to bring the
government in as a key holder.

(The shift of focus away from telephone communications to data is an
important one. I can see several reasons. First, this allows wide
deployment by integration into next-gen operating systems. A few
vendors can be "incentivized." Second, voice systems are increasingly
turning into data systems, with all the stuff surrounding ISDN,
cable/telco alliances, "set-top" boxes, voice encryption on home
computers, etc. Third, an infrastructure for software key escrow would
make the backward extension to voice key escrow more palatable. And
finally, there is a likely awareness that the "terrorist rings" and
"pedophile circles" they claim to want to infiltrate are more than
likely already using computers and encryption, not simple voice lines.
This will be even more so in the future. So, the shift of focus to
data is understandable. That it's a much easier system in which to get
40-60 million installed systems _almost overnight_ is also not lost on
NIST and NSA, I'm sure.)

In other words, a different approach than with Clipper, where
essentially nobody was planning to buy the "Surety" phones (except
maybe a few thousand) but the government role was very prominent--and
attackable, as we all saw. Here, the scenario might be to get 40-60
million units out there (Chicago, next iteration of Macintosh OS,
maybe Sun, etc.) and then, after some series of events (bombings,
pedophile rings, etc.) roll in the mandatory aspects.

Enforcement is always an issue, and I agree that many bypasses exist.
But as Diffie notes, the "War on Drugs" enlistment of corporations was
done with various threats that corporations would lose
assets/contracts unless they cooperated. I could see the same thing
for a software-based key escrow.

A potentially dangerous situation.

I was the one who posted the Dorothy Denning "trial balloon" stuff to
sci.crypt, in October of 1992, six months before it all became real
with the announcement of Clipper. This generated more than a thousand
postings, not all of them useful (:-}), and helped prepare us for the
shock of the Clipper proposal the following April.

I see this software-based key escrow the same way. Time to start
thinking about how to stop it now, before it's gone much further.

Putting Microsoft's feet to the fire, getting them to commit to *not*
including any form of software-based key escrow in any future releases
of Windows (Chicago or Daytona) could be a concrete step in the right
direction. Ditto for Apple. 

I'm sure we can think of other steps to help derail widespread
deployment of this infrastructure.


--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
"National borders are just speed bumps on the information superhighway."


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
"National borders are just speed bumps on the information superhighway."

On Tue, 26 Jul 1994, Timothy C. May wrote:

> Here's the rub:
> 
> * Suppose the various software vendors are "incentivized" to include
> this in upcoming releases. For example, in 30 million copies of
> Microsoft's "Chicago" (Windows 4.0) that will hit the streets early in
> '95 (betas are being used today by many).
> 
> * This solves the "infrastructure" or "fax effect" problem--key escrow
> gets widely deployed, in a way that Clipper was apparently never going
> to be (did any of you know _anybody_ planning to buy a "Surety"
> phone?).
> 
> (Why would _anyone_ ever use a voluntary key escrow system? Lots of
> reasons, which is why I don't condemn key escrow automatically.
> Partners in a business may want access under the right circumstances
> to files. Corporations may want corporate encryption accessible under
> emergencyy circumstances (e.g., Accounting and Legal are escrow
> agencies). And individuals who forget their keys--which happens all
> the time--may want the emergency option of asking their friends who
> agreed to hold the key escrow stuff to help them. Lots of other
> reasons. And lots of chances for abuse, independent of mandatory key escrow.)
> 
> But there are extreme dangers in having the infrastructure of a
> software key escrow system widely deployed.
> 
> I can't see how a widely-deployed (e.g., all copies of Chicago, etc.)
> "voluntary key escrow" system would remain voluntary for long. It
> looks to me that the strategy is to get the infrastructure widely
> deployed with no mention of a government role, and then to bring the
> government in as a key holder.
> 
> 
> I was the one who posted the Dorothy Denning "trial balloon" stuff to
> sci.crypt, in October of 1992, six months before it all became real
> with the announcement of Clipper. This generated more than a thousand
> postings, not all of them useful (:-}), and helped prepare us for the
> shock of the Clipper proposal the following April.
> 
> I see this software-based key escrow the same way. Time to start
> 

I was just reading through my mail when it hit me. If the NSA and the FBI 
want to put their software based key-escrow systems into software like 
Chicago, why don't we create pamphlets to send out to businesses and the 
people of the United States. In the pamphlet, there is a little glossary 
for some of the terms and acronyms used and explanation of the Govt. 
would like to do with Clipper Chip and YOUR phones and computers. Or we 
could try another route. Most radio stations and TV stations give groups 
free air time for public service anouncements. We could create videos 
about what we are talking about to make the public aware....
 
Aaron

Look at the success RSA has had with Apple building their certification
structure into System 7 Pro.  There was discussion on sci.crypt about
whether PGP (or any non-hierarchical certification structure) could be
used, and the consensus seemed to be that the hooks aren't there.  If you
want to inter-operate with this software, which will presumably be widely
available in the future, you will have to join the official certification
hierarchy.  So long, web of trust.

Now, this approach does seem vulnerable to reverse-engineering the OS,
getting in below the software layers which you are supposed to use, to
defeat the restrictions the software is trying to place on you and have
built-in encryption of your choice.  But this will be a big job.  Still,
maybe the best approach when MSoft comes out with this encryption built-
in will be to get software out which will bypass it while still using
the other value-added features like hot links, automatic encryption/
decryption, etc.  Otherwise they may well succeed in getting a de facto
standard into place which does not protect individual privacy.

Hal

Cypherpunks,

Sorry I haven't been able to participate in the thread I started, but
my own post has yet to make it here to "Notcom," and later posts are
dribbling in out of order, without prior context, etc. (I suspect the
problem is at Netcom's end, e.g., refusing mail, and not at Toad's
end.)

Hal Finney wrote:

> used, and the consensus seemed to be that the hooks aren't there.  If you
> want to inter-operate with this software, which will presumably be widely
> available in the future, you will have to join the official certification
> hierarchy.  So long, web of trust.

I think this is happening. I just got a forwarded response from a
Microsoft paralegal, and he confirms that Microsoft is working on
various aspects of key escrow, software key escrow, etc. Mostly, he
says, for export to countries with key escrow (!!). I don't feel at
liberty to post his response here, but I encourage Blanc Weber, who
handled the intermediary exchange, to get permission to do so, or to
just do so on his own authority.

I should also note that the Microsoft legal guy claimed I was "off a
little" (which could be "a lot" if he was being facetious) in my
speculations about Chicago, in '95. We'll see in 1995, I guess. In
any case, getting confirmation that Microsoft is working on key escrow
_at all_ is a simply amazing development, I would say.

(I don't know if they're planning to use the algorithm that Matt Blaze
described, the one from Trusted Information Systems. Others may know.)


> built-in encryption of your choice.  But this will be a big job.  Still,
> maybe the best approach when MSoft comes out with this encryption built-
> in will be to get software out which will bypass it while still using
> the other value-added features like hot links, automatic encryption/
> decryption, etc.  Otherwise they may well succeed in getting a de facto
> standard into place which does not protect individual privacy.

I agree with Hal completely. Everything is pointing to the existence
of a heretofore unknown cooperationg between Microsoft and NIST on a
software key escrow system. The TIS work looks to be the key.

More than this morning, I stand by my speculation that a serious
proposal exists to implement some form of key escrow in software.
This could establish a "de facto standard" faster than anything
connected with Clipper ever could.

Vigilance!

--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
"National borders are just speed bumps on the information superhighway."

Tim wrote:

> Cypherpunks,
> 
> Sorry I haven't been able to participate in the thread I started, but
> my own post has yet to make it here to "Notcom," and later posts are
> dribbling in out of order, without prior context, etc. (I suspect the
> problem is at Netcom's end, e.g., refusing mail, and not at Toad's
> end.)

    Last night noting an absence of list mail I pinged and found
    toad.com live but got no response (then) from majordomo on a
    "who cypherpunks" query. Tried first at 00:30 then again at
    02:00.  Netcom allowed the responses to be received at 04:49
    within two seconds of each other!  I append the headers to
    document this amazing disservice.

    Since 47 of the 530 cypherpunks are netcom users, I think
    the rest of the list should understand the difficulties we
    face in getting posts in any timely fashion.  It does make
    discourse difficult. 


From owner-cypherpunks  Wed Jul 27 04:43:14 1994
Return-Path: <owner-cypherpunks>
Received: by toad.com id AA27614; Wed, 27 Jul 94 04:43:14 PDT
Received: from netcom.com (netcom13.netcom.com) by toad.com id AA27570; Wed, 27 Jul 94 04:42:56 PDT
Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom)
	id EAA10938; Wed, 27 Jul 1994 04:43:12 -0700
From: bart@netcom.com (Harry Bartholomew)
Message-Id: <199407271143.EAA10938@netcom13.netcom.com>
Subject: EMAG> TJOAUC (E-Zine) (fwd)
To: cypherpunks@toad.com
Date: Wed, 27 Jul 1994 04:43:11 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1329      
Sender: owner-cypherpunks@toad.com
Precedence: bulk

>  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

T.C. May wrote:

 > including any form of software-based key escrow in any future releases
 > of Windows (Chicago or Daytona) could be a concrete step in the right
 > direction. Ditto for Apple. 
 > 
 
 	Seems like Microsoft was just allowed to wiggle out from
 	under a gov't action recently.  I wonder if there was a
 	quiet deal done?


Chuck