From: ph@netcom.com (Peter Hendrickson)
To: cypherpunks@toad.com
Message Hash: 0ca8a795460f9a674c16277e43b18692d9e577cd9ee594d97a3df2b098e560ed
Message ID: <v02140b00aedf4a134af2@[192.0.2.1]>
Reply To: N/A
UTC Datetime: 1996-12-19 20:08:25 UTC
Raw Date: Thu, 19 Dec 1996 12:08:25 -0800 (PST)
From: ph@netcom.com (Peter Hendrickson)
Date: Thu, 19 Dec 1996 12:08:25 -0800 (PST)
To: cypherpunks@toad.com
Subject: Executing Encrypted Code
Message-ID: <v02140b00aedf4a134af2@[192.0.2.1]>
MIME-Version: 1.0
Content-Type: text/plain
At the last meeting references were made to processors which only
execute encrypted code. Decryption occurs on chip.
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.
Even if it is feasible to determine the secret key stored on the
chip, software piracy is still hard because it is not possible to
execute the code on another chip without authenticating it.
One could execute the code on another architecture entirely using an
emulator, but there would be a performance price paid. It wouldn't
be worth the trouble for most software.
The manufacturer of the encrypted-code processor would protect its
instruction set using intellectual property law. Given the high
price of a fab, it is entirely feasible to stop anybody from building
a new architecture which can execute the code about as fast as
the encrypting-code processor.
Viruses are not feasible if the authentication is strong.
Retrieval of the secret key is quite difficult. Since the results
of the decryption never leave the chip, the recent attacks against
smart cards do not work. (In the case of an error, the authentication
fails and the code does not execute. No information has to leave
the chip.)
I would be interested to hear comments and corrections.
Peter Hendrickson
ph@netcom.com
Return to December 1996
Return to “solman@MIT.EDU”