From: wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Sun, 10 Jul 94 00:08:36 PDT
To: cypherpunks@toad.com
Subject: Re: Request: tamper-proofing executables
Message-ID: <9407100707.AA29634@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text/plain


Tamperproofing things that aren't hardware is difficult.
If your code is sufficiently non-obfuscated to be worth tampering with,
Bad Guys can tamper with the tamper-checking code just as easily as they
can with the useful-stuff code.  One way around this is to leave
digital-signature-checking to exterior programs, e.g. include a PGP signature
(probably in a separate file to avoid mushing it into your binaries)
and let them check the signature from their own copy of PGP.
(Or for cheapness without patent problems, distribute a RIPEM-sig instead.)

Some people have suggested code that does things like encrypt some 
critical parts of the code and decode them on the fly at runtime,
using a key that's generated by checksumming the file and XORing
with the last 8 bytes or some variant.  Sufficiently persistent Bad Guys
can respond to this by grabbing the code from memory as they run it,
and you can play games with them about decoding stuff a piece at a time, etc.
(All of this is of coure easier in LISP or interpreted languages.....)
How much work you want to put into this depends on how much effort
you think the Bad Guys are willing to spend cracking your code.

I've heard people talk about doing totally encrypted computation,
but I'm not sure whether anything practical hs been implemented.

		Bill
		
# Bill Stewart  AT&T Global Information Solutions, aka NCR Corp
# 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204 fax-6399
# email bill.stewart@pleasantonca.ncr.com billstewart@attmail.com
# ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465