Re: tamper-proof p-code

[collins@newton.apple.com (Scott Collins)]

Ray,

  Ray->In your essay, you overlook the use of pseudo-code interpreters
  > and cryptographic code mangling.

No I don't.  In fact, I specifically mention the latter.

  Ray->It is not possible to make software
  > unconditionally tamper proof, but it is possible to make it hard [...]

  Ray->If crackers had to alter just 10% of an
  > application to get it to work unprotected, I think that would be a
  > sufficient deterrent to most of them.

I agree!  I even said this in the final paragraph:

  Scott->The attack might not be cheap!  But people will do it if the
  >reward exceeds the cost.


Some of the things you mention would make a program very expensive to
`crack'.  However, as we both said: just expensive, not impossible.  It
certainly might be expensive enough to stop the particular class of attacks
you have in mind.

Your notes about remote trusted systems (e.g., Telescript) are accurate.
The difference they introduce into the scenario is that execution is no
longer under control of the attacker, and in fact the attacker can have a
piece of software that `runs', but may only run after being unlocked on the
trusted system, with the private key of the trusted system.  I specifically
mentioned and excluded this class of problems from my argument.

However, you also say:

  Ray->Here, the problem is that the code is never "decrypted" in
  >the first place.

  Ray->Imagine the task of having to create a plaintext which will generate
  > a certain MD5 hash.

No.  The code is decrypted.  It does get to the CPU.  The CPU does execute
instructions belonging to the `actual functionality' of the software.
Comparing this to finding a text with a given hash is not accurate.  (Maybe
it is accurate if the attacker tries to get between the interpreter and the
byte-codes; but not if the attacker just stands behind the CPU.)

Either the CPU gets to see the final instructions or it doesn't.  If it
never sees them it is because the program doesn't or won't run in the first
place.  I exempted this situation from my argument.  The attacker must have
at least one working copy of the software.  If the CPU _does_ see the
instructions, then the secret is out, no matter how difficult it is to
capture it ... it's still only difficult, not impossible.  My argment is
about communication, not about programming.  Like the old joke:

  A: "Would you sleep with me for a million dollars?"
  B: "...uh, sure.  Yeah, I'll sleep with you for a million bucks."
  A: "Would you sleep with me for twenty dollars?"
  B: "What do you think I am?!"
  A: "I know what you are!  Now we're just haggling for a price."

The quality and effectiveness of `protection code' (under the conditions I
gave) can never amount to anything more than `haggling for a price'.  I
think you already understand and agree with this.  The price might actually
be as much as $1,000,000.00; which could be sufficient deterrent.  To that
end, the tamper-proofing will have succeeded.

Your p-code (maybe `protected-code') proposal could be a viable product.
Don't stop.  After all, none of DES, IDEA, and RSA, are unconditionally
secure, and they serve us well.

Cheers,

Scott Collins     | "Invention, my dear friends, is 93% perspiration,
                  |  6% electricity, 4% evaporation, and 2% butter-
  collins@acm.org |  scotch ripple."                   -- Willy Wonka
..................|..................................................
Apple Computer, Inc.  5 Infinite Loop, MS 305-2D  Cupertino, CA 95014
408.862.0540   fax:974.6094   R254(IL5-2N)   collins@newton.apple.com
.....................................................................
408.257.1746  1024:669687                         catalyst@netcom.com