Re: Executing Encrypted Code

Scott V. McGuire wrote:

> You should expect software companies to make more money and for prices to
> come down.  Remember, there's not just one software company.  This scheme
> would force some of the people who would copy software to buy it,
> increasing the profits to the software companies.  So, why would the
price
> come down?  Well, because of the increased profit margin, there is now
> room for the price to come down, and since there is competition among
> software companies, at least one of them will lower prices for the
> advantage it will give them.  The others will have to follow.

And therefor I write:

	Of course that would be in a microsoft-less world where there wasn't one
company who controlled huge market shares, who dominated the industry and
who didn't have both government and 'big business' in their pocket. 
Microsoft is the great 'teflon corportation' able to shake off controversy
after controversy regarding everything from hostile marketing strategies to
product dumping.
	Since Microsoft already maintains a virtual monopoly I don't see how
making the user pay will serve justice.  In your world we'd have to pay for
whatever inferiour product is handed to us... not only limiting our choice
and freedom but making Microsoft that much more powerful.
	
My two bits, take it or leave it.

Dalban

Let me try to sketch a design for an Encrypted Code Computer (ECC).

I will start with what has become the standard architecture for Personal
Computers/Workstations.  That is:

(1) One or more CPU chips, each of which includes a RISC core, memory
management, and L1 cache.
(2) A L2 cache memory chip.
(3) A main memory bus which either includes an I/O bus or,
(4) A separate I/O bus.

If we decrypt the code on the disk, we gain almost no piracy protection
over current systems, so we must decrypt somewhere in the memory hierarchy.
If we decrypt on the main memory bus, then it will be easy to add bus
snooping hardware to catch the unencrypted program as it is accessed.
While average computer user may not do this, the foreign pirates certainly
will.  Basically the same argument applies to decrypting in the L2 cache,
since it will be easy to sample the signals between the L2 cache and the
CPU.

That leaves us with decrypting in the CPU.  Most CPU chips have separate
instruction and data L1 caches.  If we assume separate caches for our
system, it becomes logical to decrypt the code as we load it into the L1
cache.  If we assume that we are using public key cryptography to protect
the programs, where the CPU chip has the only copy of the secret key, then
we have to solve the following problems:

(1) We have to decrypt each code line in a few cycles or the system's
performance will be much worse that a similar system without encryption.
(2) We must decrypt cache lines accessed in a basically random manner.

Point (1) means we probably want to encrypt the code with a symmetric
cypher and then encrypt the symmetric key with the CPU's public key.  There
will need to be a way of telling the CPU, "Here's a new encrypted symmetric
key for code."  To avoid having to do a public key decryption on every
process/program switch, the CPU will need a cache of symmetric keys, and
the OS will have to tell it which key-cache entry to use at any point
during execution of the program.  There will have to be a way to
automatically change the key when servicing an interrupt.

Point (2) means we can't use any of the really good encryption modes, and
are pretty much limited to ECB like modes.  If we use straight ECB mode,
then our program becomes subject to a number of cypher-text only attacks.
If we can arrange our software system so code always executes at a constant
virtual address we can reduce these attacks by salting the code cache
blocks with the virtual address.  However, constant virtual addresses make
DLLs somewhat difficult.


Given this design, we need a symmetric cypher which can be decrypted with a
logic array shallower than about 100 gates (which works out to about 5
clock cycles).  We are still going to pay a performance penalty because we
are adding clocks to a critical performance path, but perhaps we can get
Steve Jobs to sell it to the masses :-).

We still have a major problem if we want a multiprocessor system.  How do
we migrate threads between processors?  It seems that we need to have the
same key on all processors (or license and keep in memory multiple copies
of the code).  If we allow the keys off-chip, then recovering them becomes
much easier.  If we keep them on-chip, then the CPU manufacturer needs to
build CPU chips which share a secret key, with all the attendant inventory
problems etc.  (And, if I can move the CPU chips to different systems, then
I can run a single key of the software on multiple systems.)


-------------------------------------------------------------------------
Bill Frantz       | I still read when I should | Periwinkle -- Consulting
(408)356-8506     | be doing something else.   | 16345 Englewood Ave.
frantz@netcom.com | It's a vice. - R. Heinlein | Los Gatos, CA 95032, USA

At 5:14 PM -0800 12/21/96, Bill Frantz wrote:
>Let me try to sketch a design for an Encrypted Code Computer (ECC).
>
>I will start with what has become the standard architecture for Personal
>Computers/Workstations.  That is:
>
>(1) One or more CPU chips, each of which includes a RISC core, memory
>management, and L1 cache.
>(2) A L2 cache memory chip.
>(3) A main memory bus which either includes an I/O bus or,
>(4) A separate I/O bus.


A useful thing to bear in mind is that there already exists such an
"Encrypted Code Computer," though it is not usually thought of that way.
Namely, a satellite t.v. decoder (or set top box). Instead of taking in
bits from a floppy disk or whatever and decrypting so as to allow the
software to be run, it takes in bits from a satellite dish receiver,
descrambles the data, and "executes" the  resulting bitstream (in the most
common case, displaying a t.v. picture).

Whether the decryption or descrambling takes place on a specific chip or in
a system comprised of several chips is almost immaterial, except for linear
factors of complexity in defeating the copy protection/tamper resistance
measures. (Notably, epoxy gunked over the PALs or microprocessors doing the
"VideoCipher II" or "Hendrickson" unscrambling, or special measures at the
chip level.)

The issue of tamper-resistance in chips has come up half a dozen times on
this list; the archives should have a bunch of longer articles on this,
including mine. As it happens, I started Intel's lab which did electron
beam testing of microprocessors, and worked on various aspects of the
tamper-resistance issue. Basically, it's hard to stop a determined attacker.

(The motivation for a satellite box attacker is more than one might
think...it isn't just getting one set of channels for free, it's about
making N instances of an account that's been paid for, so all of these N
instances will look exactly like the box for which payments are carefully
made so as to ensure continued coverage. This is called "cloning." I submit
it's exactly analogous to defeating the Hendrickson-proposed copy
protection scheme.)


>That leaves us with decrypting in the CPU.  Most CPU chips have separate
>instruction and data L1 caches.  If we assume separate caches for our
>system, it becomes logical to decrypt the code as we load it into the L1
>cache.  If we assume that we are using public key cryptography to protect
>the programs, where the CPU chip has the only copy of the secret key, then
>we have to solve the following problems:

And don't forget that internal nodes of microproceessors can be "tapped"
with an electron beam voltage contrast system. Some steps can make this
much harder, but the principle is still that internal states are capturable.

And of course the various "shake and bake" methods so much in the news
lately. (Such methods originally developed for the satellite box cloners,
interestingly enough.)

--Tim May

Just say "No" to "Big Brother Inside"
We got computers, we're tapping phone lines, I know that that ain't allowed.
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
tcmay@got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^1398269     | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."