PGP source code

[Pete Bentley]

At Tue, 04 Sep 2001 14:16:33 BST, "Nexus" writes:
>From: "Richard Clayton" <richard@demon.net>
>To: <UKcrypto@chiark.greenend.org.uk>
>Sent: Tuesday, September 04, 2001 1:34 PM
>Subject: Re: PGP source code
>[snip]
>> There are many companies that would like to ship software that only ran
>> on your machine and no other. Reading MAC addresses from Ethernet cards
>> is as nothing to encrypting the binary for your particular CPU [or four]
>[snip]
>
>The MAC address can be trivial to change dependant on your OS.   

That was Richard's point, I believe.

>Whatever
>hardware device you use, the software will have to use an OS based API or
>some form of hardware abstraction layer to query the device for whatever ID
>you are after - you just have to insert your own shim into the OS and return
>the values you want returned.   The software is at the mercy of the OS and
>if you control the OS, software loses every time IMHO.   

If the instructions to read the CPU ID register(s) are unprivileged
(ie can be executed directly by user mode code), then the OS has very
little say in the matter.  It's only where the system ID is stored in
a seperate piece of hardware (eg the Sun IDPRAM) where access is
mediated through a driver in the OS.

In the case of the Pentium ID farce, I believe it was the case that
the instructions to read the CPU ID *were* unprivileged, but that
privileged code (eg the OS) could disable the functionality.

>How many licence or
>unlock code routines use tortuous decryption or obfuscation routines only to
>end in a single conditional jump ?
>How many hardware "dongles" suffer from the same oversight ?   

From my experience in past lives as a software developer, I'd say that
a good proportion of them suffer from many holes.  However, your
average end user is not going to jump in with a disassembler to find
the holes.

Also (I think) the case Richard alluded to was not simply testing for
a specific CPU ID, it was the case where the CPU has public key crypto
onboard and there is user-level functionality to execute code
encrypted with that CPU's public key.  No other CPU would be able to
execute that code.

On the one hand it would be a wet dream for copy protectionists, but
on the other it would be a logistical nightmare for them providing new 
binaries to customers in a timely manner when they changed CPU's for
legitimate reasons...

Pete.