Beware of encrypted processors bearing gifts...

[Dave Emery <die@pig.die.com>]

Lucky Green wrote :

> 
> Actually, it is 10 million keyboards with smartcard readers. Unless Intel
> increased the lot size. I talked with a person at Intel attempting to
> purchase the devices back in October, 1996. He expressed the difficulties
> they were having finding a keyboard vendor who understood that the CPU
> should not be directly involved in the smartcard operation. From this
> discussion, I assumed the purpose of the devices is authentication.
> 
> The keyboards might be for an ecommerce solution or they might be used in
> conjunction with Intel's P7, which will support encrypted instruction sets.


	I find the notion of an extremely wide deployment (as any Intel
x86 product will be) of machines with processors that support encrypted
instruction sets and associated smart cards deeply disquieting.

	It seems to me that this is enabling technology that would allow
the insertion of autonomous encrypted 'little brothers', into operating
systems and perhaps major net applications such as web browsers as
well..  These 'little brother' observers could be made completely opaque
to even determined and sophisticated users - with encrypted code and the
potential for encryption of all their data it would require breaking the
encryption for an independant entity to understand what such an agent
was doing and who it was doing it for.  And by making support of such
agents part of the encrypted inner ring of an OS (Win99?), it might be 
very nearly impossible to run the OS without the agent or agents present
and operating properly.   And as more and more PCs are net connected,
such agents would not need to operate entirely autonomously, as they
could communicate over encrypted links with their Big Brother somewhere
else.

	The sea change in computing that would result from providing a
mechanism for secret, black box, unknowable and unalterable code to run
on the worlds personal computers is very significant.  Up to now it has
been possible, with effort and skill and intelligence, to determine what
the code of any OS or application did by decompiling it, or use of
software ICEs, debuggers, and even hardware monitors such as ICE's and
logic analyzers. Presumably an encrypted Intel processor will reveal
these secrets only to a very limited group of trusted developers, and
perhaps even then only information about the application or layer the
person is authorized to work on.

	Having both the ability to know what code is doing, and the
ability to alter it has so far detered most attempts to put unfriendly
agents into OS or applications code.  It has  been too easy to discover
them, and too easy to disable them for this to be a really effective
tool of social control, as witnessed by the failure of generations of
copy protection schemes.  But a truly secure encrypted processor changes
things a lot - both understanding what the code does and  modifying it
become near impossible.

	While one can readily understand and even sympathize with the use
of such entities to control and perhaps even largely eliminate software
piracy and other theft of intellectual property, the potential uses of
secure agents to implement more sinister social policy are frightening.

	A three way encrypted handshake between an encrypted agent that
was part of the OS and  a smart card and software at an ISP could be
used to enforce an internet drivers license law for  example, with no
packets being forwarded by the ISP without hard  authentication (even up
to biometrics) of the user.  And it would be rather trivial to disallow
use of "unapproved" software to communicate over the net, making
enforcement of GAK much more complete.  One could even use such a
mechanism to forbid use of any  uncertified software on a net connected
machine, thus making it rather hard to use such rogue applications as
PGP.

	And given that independant review of such secret OS code would be
near impossible, adding a Digital Telephony style watcher that could be
turned on via an encrypted packet from the net to record the user's
actions and what he typed or even access encryption keys or plaintext of
encrypted traffic would simply require collusion between the OS supplier
and the government, perhaps under pressure of antitrust enforcement or
other suitable incentivization.  Discovering that such a secret trojan
was in the encrypted inner kernal code would not be easy, especially if
it was only used rarely...
	
	Perhaps most sinister, as more and more of the code run on a PC
becomes encrypted and opaque, it gets easier and easier for a trojan
created not by a Big Brother state, but by criminal elements or foreign or
industrial spies, to hide amidst all the other layers of encrypted
code, safe from being detected by all but the few in possesion of the
master keys or special hardware required to understand what was going
on.

						Dave Emery
						die@die.com