User's Manual
45
10 Program protection techniques and examples
By using the SmartKey protection dongles, you have put in place a powerful deterrent against attempts to abusively
duplicate software. However, remember that a principle typical of all security systems applies to the software protection
battle too.
A security system has the same degree of vulnerability as its weakest component
Consequently, a great deal of attention must be focused not only on the type of protection but also on the protection's
software implementation methods.
In other words, using a protection dongle without accurately implementing it in the software means stopping medium-
shrewd hackers (people doing it for a hobby, occasional users, university students looking for a personal challenge,
etc.), but not criminal-commercial organizations, which may have the time, economic resources and skills to copy
software or obtain confidential data.
We therefore thought it useful to provide a list below of some techniques and useful suggestions. The choice of
techniques to use depends on individual programs, on the cost and level of confidentiality of the software and/or of the
protected data.
In general, to make life hard for potential software pirates, bear in mind the following suggestions and comments:
• Use more than one of the protection techniques indicated below.
• Distribute the protection measures along the whole program.
• If one of the protection measures is eliminated, the remaining measures should ensure that the program seems
to be working correctly for a certain time, after which it stops randomly in terms of time and method.
Lastly, remember that the psychological aspect is very important: the aggressor can never be sure that s/he has disabled
all the protection mechanisms. Whenever he thinks he has found one, the protected software will make another problem
emerge later on (even hours or days later!), and the hacker will probably be so frustrated, that he will give up attacking.
To protect your program, you should consider the typical attacks, and try to repel at least these most common cases,
which are:
•
Reverse engineering of the program and removal of any call to SmartKey API
•
Using a High Level (User Level) emulator able to intercept and record any SmartKey API call and simulate the
behavior of SmartKey API. These emulators potentially know the semantics of the API calls and can emulate
SmartKey, but with one exception: the Scrambling operation.
• Using a Low Level (Kernel or Hardware) emulator able to intercept and record physical communications on a
Parallel or USB port and simulate SmartKey's physical behavior. These emulators usually totally ignore the
communications semantics.
The following guidelines will considerably increase protection against these attacks.
10.1 General guidelines
The following guidelines apply to all SmartKey models.
10.1.1 Check the dongle in different points of your program.
The program should not control presence of SmartKey in only one point of the execution. SmartKey control should be
duplicated in various points of the program. The Locate/Open operation can be executed at start only, but the
Scrambling operation should be executed in many other points.
10.1.2 Extensive use of the Scrambling operation
The Scrambling operation should be used to control the presence of a real token SmartKey.
The control must be performed by first calculating a set of input pairs and output strings of the Scrambling operation.
When the operation has been started, some couples must be compared with the result of the same operation on the
current SmartKey.
During execution, you must select the couple to be controlled, using a combination of both random and deterministic
elements. For example, the choice should depend on: a random value, the system's current time, your program's point of
execution, and any other variable that could differ from one program to the other.