(LW-HUG) Copy Protection for Delivered Systems...

Greetings to the Group --

I have been looking at the SG-Lock device -- built by SG Intec of 
Kiel, Germany (http://www.sg-lock.com/en/index.php) -- as a possible 
inexpensive way to protect "delivered" Lisp application systems from 
surreptitious copying etc.

The SG-Lock is a small USB "dongle" device that has an internal 
processor and FLASH memory that is able to encipher/decipher data 
using TEA (http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm) as 
the base block cipher algorithm.

My interest is to make it "difficult" for someone to simply make off 
with a commercial application coded in Lisp and "deliver"ed as an 
Application.exe (in Windows).  We build a system that lives in custom 
embedded hardware and so such a dongle would be "inside the box" and 
not something that the user would have to "fiddle around with".

Best that I can tell, the SG-Lock is not really cryptographically 
secure in the sense of "hiding" a secret key in protected hardware 
(e.g., NIST FIPS 140-2/4) as the key is just downloaded and lives in 
FLASH memory on the dongle which is fairly easy to recover (break the 
physical thing open and look at it with one means or the other (I 
used to do a vaguely similar thing decades ago with 1/2-inch magnetic 
tape and a few drops of alcohol with a suspension of fine powdered 
iron -- hordes of little magnetized iron stripes would appear as the 
alcohol dried -- 800 to the inch in those ancient days -- the real 
fun was to decode, under a microscope, what they meant in the NRZ 
encoding used  :))

In addition, the SG-Lock device uses TEA for the encipherment 
algorithm which is not, best that I can tell, all that secure (in a 
formal certified crypto sense).

However, there is an old saying: "How much security do you need 
anyway?"    Answer - "As much as you can afford."

....and I *can* afford the SG-Lock at about $30 USD :)

There are several obvious ways to proceed:

(a)  Simply encipher (in part or in whole) the Application.exe 
(Windows) file before shipping with a unique key using TEA and 
download that key to the SG-Lock. At power-up, have an intermediary 
program that deciphers the Application.exe file with the SG-Lock 
device loaded with the key and supplied to the user and then start 
the deciphered Application.exe. Problem:  If someone had access to 
the enciphered Application.exe and the SG-Lock, they could easily 
(well, if only partially enciphered, easilyish) decipher the file and 
copy that and use it - spread it about etc.

(b) Have the Application.exe call the SG-Lock during startup and do 
some simple "crypto thing" and then return the symbol :proceed if all 
is well or nil if not and stop. Problem: With a bit more reverse 
engineering, one could simply NOP out the dongle check (scan for 
assembly that leaps into the Windows USB driver thingus or, even 
better, just replace the .dll supplied by SG-Lock with your own that 
always returns :proceed).  Simple.

(c) Similar others come to mind...   ...and they are no better.


The fundamental problem is that the SG-Lock is not able to securely 
store a secret key (what do you expect for $30? I am not criticizing).

There is no way that I see to ever make this system 
"cryptographically secure" -- especially in a way 
transparent/acceptable to users (i.e., no unique pass phrases etc).

There are procedures and things in the SG-Lock .dll/library that do 
things like provide a requirement to initialize the .dll with a long 
"customer id" etc - but those would be fairly easy to get around with 
some reasonably good hack work - Clearly(ish), any half-decent 
mechanism will depend on the TEA encipherment.

Perhaps the device could be used at run-time -- for example, what if 
I were to (somehow - an exercise for the student) TEA encipher a few 
key/critical Lisp application functions (compiled code of course out 
on the heap on the development PC) with a unique key just before the 
system is being "Delivered". When the Application.exe system starts 
up, part of the start-up sequence would be to decipher the several 
functions using the supplied SG-Lock and the unique key and replace 
them with the deciphered versions on-the-fly.

Still not "cryptographically secure", of course -- really "security 
by obfuscation" but it *would* be a bit more difficult to get through 
as everything would happen within the dynamic Lisp system and not 
just with static files on the disk - on the other hand, perhaps that 
just makes it easier... (however, there would be no symbol names, or 
compiler, or delivery mechanism in place - just 50mb of RAM - it 
might actually be fairly difficult to duplicate the deciphered system 
- e.g., how do you "deliver" an already "deliver"ed system...).

Any thoughts on this......  ...especially by someone that knows more 
than I do about the internal structure of LW.

Regards,

Jack Harper
Secure Outcomes Inc
http://www.secureoutcomes.net

ps - It might be interesting to see what the GC might make of an 
enciphered function - might work and might not :)