Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!hao!noao!mcdsun!nud!rover!mph
From: mph@rover.UUCP (Mark Huth)
Newsgroups: comp.sys.amiga
Subject: Re: An Idea for Hardware Protection (long)
Message-ID: <751@rover.UUCP>
Date: 13 Jan 88 23:40:57 GMT
References: <8801090958.AA20842@ucscb.UCSC.EDU[ <4779@videovax.Tek.COM> <8801110635.AA03499@ucscb.UCSC.EDU> <4782@videovax.Tek.COM>
Reply-To: mph@rover.UUCP (Mark Huth)
Organization: Motorola Microcomputer Division, Tempe, Az.
Lines: 48
Keywords: bongle dongle gongle hongle jongle kongle pongle songle wongle

In article <4782@videovax.Tek.COM[ stever@videovax.Tek.COM (Steven E. Rice, P.E.) writes:
[
[Larry responded:
[
[>   I was thinking about this (because of mail I got on the subject) and
[> decided that the security checker should also be the entire I/O chip, with
[
[I'm sorry, but that is hardly consistent with the world we live in!  If I
[can get at the internals of the machine *at all*, I can determine what is
[going on and fudge a way around it!  If nothing else, I can insert a bit
[of hardware in the path to the dongle port that causes an exception when
[an access attempt is made.  I can then handle the exception and drop into
[a debugger, with a very good idea of what the program expects to do with
[the dongle data.
[
[Or, I can hook up a logic analyzer to the bus [Tektronix makes them, if
[you're in the market 8^) ] and analyze the instruction stream associated
[with various port accesses.  Once I have built up a picture of what is
[going on, I can build substitute hardware and software that couldn't give
[a fig about whether I dongle or don't. . .
[
Well, then, how about if the hardware protection is on the uP chip - 
say a DES encoder/decoder (modified, of course, so NSA can't read our
programs) which translates the bus accesses into encrypted giberish.
Go ahead, get out your analyzers.  Everything on the bus is encrypted.

This works, but is very inconvenient.  Let's say your uP chip gets
fried by the neighbors RADAR maser.  Now you have to get the software
vendor to supply you with new copies of the encrypted software.  Of
course the software vedor doesn't believe that your uP got fried, so
he accuses you being a pirate.

To get around the previous problem, the keys would have to be
administered by, say, the chip vendor, who would supply the software
vendor with the key given the uP serial number.  New keys could only
be given out given evidence of the death of the old uP chip.

Of course, vary sophisticated pirates with acce4ss to microprobe
equipment would simply remove the case from the uP chip and probe its
internal buses to decipher the software, or perhaps simply steal the
key from the chip and decrypt the code externally.  Of course, by now
the pirates have a couple of hundred thousand dollars invested in
equipment - probably easier to bribe the chip vendor.

Unfortunately, thieves exist.  Locks only increase the required
sophistication of the thieves.

Mark Huth