IMHW400@INDYVAX.BITNET (07/01/88)
Many (most?) people think that the SID register on a VAX is a handy place
to get a unique value for use in protecting software. Even some vendors
believe this. Unfortunately, it isn't so. The SID is made up mostly of
hardware and microcode rev. levels, option flags, and such. I know of one
product that stopped working at a site that had just gone to a higher rev.
level on one of the CPU boards, for example.
Using the SID for security is not a good idea. Take a look at the VAX Hardware
Handbook, and see:
o how the format of the SID varies wildly from one processor to another;
o that only a few processor types have anything resembling a serial
number *anywhere* in the SID.
***********
Now that I've demolished one suggestion, let me provide another: do any
of you know whether the new License Management Facility has space reserved
for third parties, so that we can use it to protect/manage our own stuff
as well as DEC's? I imagine that this would require registration with DEC,
just like for facility codes in condition longwords, but that should be no
problem for a commercial product. I wonder if the key-recognition algorithm
is secure enough that the key-*generation* software can be widely distributed?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mark H. Wood IMHW400@INDYVAX.BITNET (317)274-0749 III U U PPPP U U III
Indiana University - Purdue University at Indianapolis I U U P P U U I
799 West Michigan Street, ET 1023 I U U PPPP U U I
Indianapolis, IN 46202 USA I U U P U U I
[@disclaimer@] III UUU P UUU IIIEPRF@SNYCENVM.BITNET (Peter Flass) (07/01/88)
> >a friend of mine has a problem with his software. He wants to protect it >against using without having his licence. > >There might be 3 ways for doing such a protection: > >- Reading the CPU identification and testing it in the program >- ... > >- How can we get the cpu identification (F$GETSYI("SID")??) from within > the program and is this a secure method? My experience has been that the SID register is *NOT* a constant, at least on the 750. We have had major problems with a purchased software package which tries to use it for protection. After several problems the vendor finally had to send us an unprotected version. -Pete +-----------------------------------------------------------------------------+ | | | PETER FLASS BITNET: EPRF@SNYCENVM (PREFERRED) | | Director of Computing Services INTERnet: ESCFLASS@UBVM.CC.BUFFALO.EDU | | SUNY Empire State College AT&Tnet: (518)587-2100 X350 | | 2 Union Avenue | | Saratoga Springs NY 12866 | | | +-----------------------------------------------------------------------------+
LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (07/05/88)
[In response to a message asking about methods of identifying a CPU for soft- ware protection, the author writes:] > - How can we get the cpu identification (F$GETSYI("SID")??) from within With the system service SYS$GETSYI. TRUE. > the program and is this a secure method? This is reasonably secure, provided you LINK/DEBUG. Presumably, you mean LINK/NODEBUG, though it's beside the point. However, the format of the SID register is different for different processors (in the case of the 11/78x, I know that in addition to the serial number the register also contains the ECO/FCO level, so you have to be carefull to look at only the serial number portion unless you want your software to stop working every time the machine has a field upgrade), also all microVAX IIs have the same serial number. FALSE. The ONLY VAX CPU ever to have a serial number in the SID was the 780 (and, of course, the 785). Even then, there were only 12 bits of serial number, and there were a lot more than 4096 780's produced! > - How can we get the HW Ethernetadress from within the program. I'm sure there is a $QIOW call to get this Yes. A SENSEMODE QIO to the interface. ****** By the way, does anyone know of any documentation on the ethernet device drivers--and why are they not included in the I/O user's guide? ****** They are fully, if sometimes cryptically, documented. Be sure you check the right manual: The I/O User's Guide comes in two parts. The Ethernet drivers are documented in Part 2. (Older manuals may call the chapter "DEUNA and DEQNA Drivers", but it applies equally well to all DEC Ethernet interfaces. Also, the V5 version of the documentation is considerably clearer and easier to understand.) -- Jerry
OBERMAN@ICDC.LLNL.GOV ("Kevin Oberman, LLNL, 422-6955", 415) (07/06/88)
>Now that I've demolished one suggestion, let me provide another: do any >of you know whether the new License Management Facility has space reserved >for third parties, so that we can use it to protect/manage our own stuff >as well as DEC's? I imagine that this would require registration with DEC, >just like for facility codes in condition longwords, but that should be no >problem for a commercial product. I wonder if the key-recognition algorithm >is secure enough that the key-*generation* software can be widely distributed? I have been told that DEC intends to make the VMS LMF available to third parties at some time. To the best of my knowledge there is as yet no actual commitment from DEC, though. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
EVERHART%ARISIA.DECnet@GE-CRD.ARPA (07/11/88)
Re use of LMF for non-DEC vendors: Remember please that DEC's reason to go to LMF is mainly that they want to speed up delivery problems by sending pretty much EVERY one of their products to everyone (via cdrom), and allowing sales to be just a piece of paper, not having to maintain zillions of interlocking kits. A non-DEC vendor does NOT have this excuse. I find copy protection to be sufficiently offensive on our VAX that I will strenuously object to ANY attempt to use such. Nobody can guarantee he'll be in business in a year, really, and I can't guarantee my CPU ID or any other number about my processor will remain unchanged over years. Attempts to tie software use to being able to call a vendor are VERY risky for purchasers for this reason alone. They can also cost sales. Example of the latter: a CASE vendor lost a bunch of sales at one of our divisions because they insisted on using the Ethernet address of the vaxstations to copy protect. Problem was a number of the vaxstations had only the serial cards, no Ethernet. Company wouldn't change the product, so were disqualified. They deserved it. I believe boycotting copy-protected software to be the appropriate and correct general response, for all our protection. Glenn Everhart Everhart%Arisia.decnet@ge-crd.arpa