Path: utzoo!attcan!uunet!munnari!otc!metro!ipso!stcns3!stca77!peter
From: peter@stca77.stc.oz (Peter Jeremy)
Newsgroups: comp.arch
Subject: Re: built-in security features
Keywords: computer security, network security
Message-ID: <402@stca77.stc.oz>
Date: 23 Jan 89 21:06:23 GMT
References: <8846@nsc.nsc.com> <5995@polya.Stanford.EDU>
Reply-To: peter@stca77.stc.oz (Peter Jeremy)
Organization: Alcatel-STC, Alexandria, AUSTRALIA
Lines: 31

In article <5995@polya.Stanford.EDU> andy@Gang-of-Four.Stanford.EDU
(Andy Freeman) writes:
>The world does change.  Some time before the IBM-PC was introduced,
>"someone" suggested anti- software piracy features to Intel.  The
>basic idea was to have dealers trap-door encrypt code, using a
>processor-specific number, before delivering it to their customers.
>The cpu chip would then decrypt the code in real-time and execute it,
>but only if the dealer had encrypted it for that particular chip.

The IBM/370 has a unique CPU ID available via a supervisor instruction.
If the OS made it available, this could presumably be used by a software
package to verify that it was running on the licensed hardware. (Although
I seem to recall the this instruction was one that did something slightly
different under VM).  Probably most other mainframes (and early mini's)
have something similar.

This is not as secure as encrypting the code, but I don't think mainframe
software piracy is as big as problem as PC stuff.

>Intel's response was that they sold chips and that software piracy
>helped them sell more.

Also, building unique ID's into chips adds extra complexity into the
manufacturing process.  And what happens when the CPU fails?  This would
not be a big a problem for mainframes, since the ID could be a bunch of
straps (or a ROM) which can be changed by the field engineer.
-- 
Peter Jeremy (VK2PJ)         peter@stca77.stc.oz
Alcatel-STC Australia        ...!uunet!stca77.stc.oz!peter
41 Mandible St               peter%stca77.stc.oz@uunet.UU.NET
ALEXANDRIA  NSW  2015