Re: Executing Encrypted Code

["Timothy C. May" <tcmay@got.net>]

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."