From: ph@netcom.com (Peter Hendrickson)
Date: Thu, 19 Dec 1996 22:57:15 -0800 (PST)
To: Bill Frantz <cypherpunks@toad.com
Subject: Re: Executing Encrypted Code
Message-ID: <v02140b07aedfe64543d0@[192.0.2.1]>
MIME-Version: 1.0
Content-Type: text/plain


At 9:52 PM 12/19/1996, Bill Frantz wrote:
>At 12:08 PM -0800 12/19/96, Peter Hendrickson wrote:
>> If each chip has a unique public/secret key pair, and executes
>> authenticated code only, there are some interesting implications.

>> Software piracy becomes difficult, if not impossible.  Code is sold
>> on a processor by processor basis.  Code for a different physical
>> processor cannot be decrypted or executed.

> This makes backup hard.  That is the rock the routine copy protection hit
> up against.  There were many, me included, who simply said, "If your
> product is copy protected then I will buy from your competitor."

No, you can backup just as much as many times as you like.  The code
isn't stored on the chip permanently, it is only decrypted there.

There is a similar problem, though.  If your processor dies you could
lose your software library.  There are ways to mitigate this.  One is
for the vendors to just trust people and reissue the code to a new
processor.  Of course, you track how often you have to do this.

Or, you could turn in the broken processor and have the manufacturer
certify that it was turned in to the software vendors and that
a new version of the software should be generated.

This might not be so important if you generally pay for metered software.

>> Viruses are not feasible if the authentication is strong.

> So is user written code, public domain code etc.  If there is an
> un-encrypted mode for that kind of code, then viruses again become
> possible.

User written code is harder to arrange, it is true.  You might have
a way to execute non-authenticated code but at a speed comparable to
an emulator.

Or, you might just have another computer for running your own code.
Right now it is not uncommon for a software library to exceed the
value of the machine.  It might actually be economical to have two
machines if one of them can support a rich software library which
doesn't cost as much money because it can't be pirated.

Free software is still possible to run at full speed, but it has to
be authenticated.  The free software writer just has to do whatever
the software vendor had to do to get it okayed.  This makes it
harder to release free software, but the effort is still a small fraction
of the work required to build a significant application.  Getting it to
execute for particular processors is easy.  You could release a piece
of software which takes code and encrypts it for your particular
hunk of silicon.

If you could offer otherwise free software for, say, $20 and know
that everybody using it will pay, many people might consider that
to be a great deal.  Right now the mechanisms of moving the software
are too expensive to really make it feasible for something under $20.

Development might be a bit tricky, but there are workable solutions.
The manufacturer could release special processors which have an
additional authentication mechanism for software developers which
is specific to each developer.  They could authenticate code to run
on their own machine, but not on anybody else's.

This does make it possible for software developers to pirate software
(if the can get a secret key), but if the number of development processors
is low, this could be manageable.

If the environment was well defined, you could conceivably develop
in a high level language on one platform, but deploy for sale on the
decrypting-processor platform.

Peter Hendrickson
ph@netcom.com