From: collins@newton.apple.com (Scott Collins)
Date: Mon, 11 Jul 94 01:57:19 PDT
To: cypherpunks@toad.com
Subject: Tamper-Proof Software? No!
Message-ID: <9407110856.AA26386@newton.apple.com>
MIME-Version: 1.0
Content-Type: text/plain


Hello,

Software only products cannot be made unconditionally tamper-proof, for the
following definition of `tamper-proof':

  "An attacker, on their own machine (over which they have complete
control), given a copy of the software that `runs' on that machine but
includes mechanisms so that it won't run under certain conditions (the
`tamper-proofing'), cannot produce a piece of software that lacks the
tamper-proofing."

By this definition, I am not addressing, e.g., pirates attempting to unlock
a software distribution without the key, nor getting a bogus agent to run
in a protected environment like Telescript, nor programs where a
significant part of its functionality happens inside a physically
tamper-proof `dongle'.

Tamper-proofing is a fundamentally different problem from secret
communication.  The latter is `How can two parties exchange information
such that no third party can learn it?'  The former is `How can one party
tell a secret to a second party, and at a later time, take it back?'  You
can't `un-tell' a secret.  The functionality of your program is the secret.
If that secret is revealed (and when you run the program, it will be)
there's nothing left to protect; the secret is out.

Tamper-proofing mechanisms amount to questions, answers, and actions.  Each
can be supplied by either the software itself or some outside entity (e.g.,
the OS, a `dongle', a network key-server, etc.).  They come in many forms,
but they can be reduced to "Is this the original software?", "yes" or "no",
and `continue' or `quit'.  In the case where it is the software itself that
decides whether to run or quit (and since the attacker has complete control
over the environment, it must be), the attacker is not constrained to
defeating an arbitrarily hard authentication scheme.  It is sufficient to
avoid the test or refuse to quit.  Replace each call to a tamper-detection
routine with a call to a routine that has the same side-effects as the
original would when no tampering has occurred (which can be observed).

Thus, if the software checksums itself---remove the code that asks for the
checksum, or remove the code that quits if the checksum doesn't match.  If
the checksum is required to decrypt some part of the program---build a copy
of the software that is already decrypted, or use the saved checksum from
an original run.  If the program uses the value returned by a dongle to
decrypt part of itself---watch it happen once, then keep the decrypted
part.  If a network server won't give you an open socket until the software
answers an unpredictable question about itself that the modified program
cannot answer---relay the question to an unmodified instance of the
program.

Sooner or later, in the course of execution, the `useful' part of your
software will be presented, unencrypted and ready to run (if not without
strings) to the CPU.  Even if this happens only a little bit at a time, the
attacker can record those hunks and assemble them into a new, unencumbered
package.  The attack might not be cheap!  But people will do it if the
reward exceeds the cost.  If there is functionality you want to protect
unconditionally, don't give it away!  Sell a service instead.

Hope this helps,


Scott Collins   | "That's not fair!"                         -- Sarah
                | "You say that so often.  I wonder what your basis
   408.862.0540 |  for comparison is."                 -- Goblin King
................|....................................................
BUSINESS.    fax:974.6094    R254(IL5-2N)    collins@newton.apple.com
Apple Computer, Inc.  5 Infinite Loop, MS 305-2D  Cupertino, CA 95014
.....................................................................
PERSONAL.    408.257.1746       1024:669687       catalyst@netcom.com