Tom

As for adding keys to your software, yes, I believe it's a good thing, but you 
have to remember that simply locking up your software really, really tight is 
not a good solution.  They idea is to balance protecting your software but not 
putting the screws in so tight that the client can't use it properly.

It's really really easy to get the CPU serial number programmatically, and IBM 
even has a service you can call to get the machine information from an 
authorized or non-authorized environment.  You can get it from COBOL as well as 
via C.  

As for protection, many vendors simply "scramble" the characters of the CPUID 
and the "expiration date" they want to assign among either a bunch of useless 
characters or keep single bytes all over the place within your program, then 
you get the CPU serial (and machine type information if you want to use that 
also), and the current date, then you simply compare the values you know (the 
CPUID and other data you authorized in your program), with the values you just 
got from the system you are executing on.  If they don't match (serial number, 
etc.) then you can just send a message that you have expired or just end 
without saying anything (which is very unhelpful).  Then if that matches, you 
compare the dates, and if it's within the end date you allowed, then you just 
go on as if nothing happened.  If you are getting close to the date (i.e. the 
last 30 days) then you can put out a "warning" message that you will expire 
soon.  You can (and probably should) add code to allow "grace" period.  

Now, if you want to get really fancy, you can take the information that you 
normally would have kept within your code, and instead place it in a key record 
(some encrypted record that you provide to the user to make available to your 
program, either in a dataset or as a parm to the execution.  You program should 
then have some decryption code that checks the provided key information against 
the execution time information (CPUID, MACHINE Type, current date), just like 
the previous method, except that you have externalized the "key" and can 
replace it very easily for your client.

The encryption method can be a secure one (128bit or 256 bit secure method or 
you can devise your own encryption code, even something as simple as inverting 
each character by some known amount and also having scrambled up the order of 
the information is probably more than enough to do what you want.  After all, 
most sites are not really trying to steal your code, and besides a really 
concerted and smart person with enough time can break your encryption anyway, 
but the idea is really just to remove the temptation to keep copies of your 
code and/or sell them to other people.

I have literally seen probably 100 (or more) different ways of implementing the 
code, and everyone has their favorites and everyone thinks that theirs is the 
best (but I know mine is), and there is no real "right" way to do it.

If you need help setting up the code to get the information from the system 
during execution, let me know and I'll help you, as for coming up with the 
encryption code, you probably want to do that yourself so that you know that no 
one else will give your method away.  But if you need help I can help you there 
as well.  It's really very simple once you know where to get the information at 
run time.

What you will notice is that once you are able to get the data from the system, 
it becomes more addictive and you will want to start getting things like the 
jobname of the job that is executing you, or the owning userid and such.  The 
skys the limit once you start down that road.

Just remember that you don't need to go overboard. You certain can if you want, 
but protection doesn't have to be overly complex to be effective.

Brian  

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to