Preventing date rollback

David Cornutt cornutt at freedom.msfc.nasa.gov
Sat Jan 26 04:02:01 AEST 1991


I once encountered a protection scheme that seemed to be pretty good for
both the vendor and the user.  The software was Verilog-XL running on
a Sun-3 that I sysadm'ed some years ago.  It used a pseudorandom key
generated from the date, the serial number (extracted from the Sun's
ID ROM), and a passcode that was stored in a shell script that had
to be sourced before running the software.  The key was somehow
generated so that it authorized the software for a particular time
interval.  It somehow stored the date of last invocation in a touch
file.  It would catch date rollbacks, but allowed some limited rollback
to make up for clock resets, time zone changes, and the like.  To prevent
accidents, as I recall, it compared the current time at each invocation
to the stored time of last invocation, and if the difference was too
great, it prompted to user to double-check the system clock before
proceeding.

One time we lost the ID ROM on the Sun.  (A decoupling cap next to it
on the CPU board caught fire and melted it.  After this we started
referring to it as the "arc welder in disguise." :-)  When the board
was replaced, and a new ROM was installed, we just called up Verilog
and they gave us a temporary 30-day password over the phone, so that
we could continue operating while the license amendment was being
amended to reflect the change.

The protection scheme in no way hindered backing up or restoring the
software.  It did very much hinder using it on an unlicensed machine.
(The Verilog folks invited us to try to break it.)  It was a nice
scheme, and I wouldn't hesitate to recommend it.  (On top of that,
the package itself was a very good package.   If this be a blatant
plug for Verilog, so be it.)

BTW, ordinary CPU upgrades/replacements did not post any license
problem with this machine.  You just removed the ID ROM from the 
old board (it was socketed), and put it in the new one.  Actually
losing the ROM itself was very rare.  Of course, this scheme
depended on this hardware feature of the Sun, and would have
been harder to implement on a machine that didn't have any
hardware identification.

-- 
David Cornutt, New Technology Inc., Huntsville, AL  (205) 461-6457
(cornutt at freedom.msfc.nasa.gov; some insane route applies)
"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."



More information about the Comp.unix.admin mailing list