The InterLok System

InterLok is more is more than an easy way to securely distribute "trialware" products. It is a sophisticated system that allows you to protect your product and customize the delivery of software authorizations to your customers using multiple tools and methods. Components of the InterLok system include our fifth generation software technology and the revolutionary new iLok smart key.

On this page we will discuss the guiding concepts and overall operation of InterLok system components so you can get a sense of the remarkable power this tool can provide to your company.

Authorization: What is it?
How InterLok sends permissions and instructions to remote copies of your application. The two types of authorization and the mechanics of creating and sending authorizations are discussed.
Ways to Store Authorizations
Options for storing software authorization information
Serial Number Authorization
When you only want to activate and uniquely mark your application.
Challenge/Response Authorization
When you want to lock an application to a particular machine, for demonstration purposes, or for all time.
Application Modes
Comprehensive look at the modes InterLok can put a locked application in, and examples of use. Unauthorized, Active Demonstration, Serialized, Expired, they're all here and they're all explained. This is the most important part of this document.
Invoking Authorization: The User Experience
Quick look at how the user enters authorization information.
Other Features
Registration capture, Installer integration and localization are discussed.
Developer Experience
What it is like to use InterLok from the developer's point of view with discussion of some of the options available.
The InterLok API: The PACE Interface
InterLok has an API locked programs can use to implement advanced features. Unlike other systems, use of the API is not required, but it is there if you need it.
Security
Notes on the security of the InterLok system.

Just as Mission Control in Houston sends instructions to its interplanetary probes, InterLok allows you to send instructions to distant copies of your application. These instructions are called authorizations, and take two forms: challenge/response authorization, which is concerned with directing the actions of your software on a particular remote machine, and serial number authorization, which is concerned with directing the actions of your software without regard to the machine it is running on. We will discuss both of these in detail in a moment.

In the same way interplanetary craft can be directed to execute various predefined subroutines, a piece of software locked with InterLok can be directed to exhibit various predefined behaviors. We call these behaviors modes. For example, an InterLok'd application can be told to enter time-limited demo mode by receiving (or being created with) an authorization for this from the software developer. A program in time-limited demo mode will display developer-defined reminder messages that the program is a demonstration/evaluation copy. These messages will increase in frequency as the end of the demonstration period approaches. Finally, unless a further authorization with new instructions is received, the demonstration period will expire and the application will enter expired application mode. Usually an application in this mode will refuse to run unless an authorization is provided.

The rest of this page discusses the specifics of the authorization methods and application modes, but the important thing to note is that InterLok allows you to be the "mission control" of your application, requiring distributed copies of your software to check-in with you as much (or as little) as you require.

To remotely serialize and unlock an application, you must transmit a serial number authorization to your customer. With challenge/response authorization, the customer gives you a challenge the remote InterLok has generated and you use this information to create and send back a response.

Serial number authorizations and challenge/response authorizations are created by the InterLok authorization generator, Satisfaction(tm). Unlike other systems that use a complicated series of letters and numbers to communicate information (i.e. DCP-234-6FACD22), InterLok authorizations are revolutionary in that they are sent and received as a series of short English words (i.e. MARS CAT BOAT RUN KING).

Also, the InterLok Satisfaction authorization generator can be automated with a NT or Macintosh server. This means that, in addition to responding to customer authorization requests through the traditional channels of phone, fax and postal mail, you can also authorize customers with a CGI enabled web site or automated e-mail system. (Of course, manual e-mail works fine too.)

Serial number authorization is the "lightweight" form of InterLok use. As the name implies, serial number authorization sends an encrypted serial number to the remote application locked with InterLok. Once serialized, an application is unlocked and may easily be copied by your customers from machine to machine. The first time a locked application is run on a new computer, it will request the user enter the serial number authorization you have provided. In this way, a program and its serial number authorization must travel together when being moved from machine to machine.

Serial number stamping is the method chosen by the publishers of many large, commercial software packages. While it doesn't stop someone from posting your software and the serial number on an anonymous FTP site or USENET group, it does mean each copy is branded with a serial number traceable back to the comprehensive customer database maintained in the InterLok Satisfaction authorization generator.

Also, unlike many serialization schemes, InterLok serial number generation has a high degree of cryptographic security. That is, there is no simple algorithm a hacker can use to generate a batch of "fake" serial number authorizations for your application. Besides the actual 32-bit serial number value, each InterLok serial number authorization uses unique, secret, information that identifies the serial number as one that belongs to your application alone. Without access to this secret information, generation of InterLok serial numbers by anyone else but you is (for all practical purposes) impossible. Even another InterLok customer cannot unlock your application.

InterLok serial number authorizations can also include an absolute date (i.e. June 23, 1997) when the serial number expires. When a serial number authorization expires, the application will refuse to execute until it receives new authorization instructions. A serial number authorization time-limited in this way cannot be circumvented by setting the clock back on the customer's computer.

Temporary serial number authorizations are useful to give customers time to evaluate your product before making a purchase (of the presumably serial number authorized) final product.

Although the serial number authorization facilities of InterLok are quite useful, developers who require serial number authorizations to contain arbitrary information should investigate InterLok's big brother, InterLok PRO. InterLok Pro serial number authorizations can carry arbitrary data, and because of this they can be used to perform developer defined actions, such as turning (sets of) features on or off, for example.

In general, serial number authorization is appropriate for lower cost and/or higher volume products where a high degree of customer convenience is required and the possible illegal copying of serial numbers and software is not a concern. Serial number authorization also makes sense if your software requires special additional hardware to perform its job (a control interface to a piece of machinery, for example), in this case copying is probably not an issue.

Challenge/Response authorization is the "heavyweight" form of InterLok security. When your application is first run on a user's machine, InterLok examines characteristics of the disk subsystem and uses it to generate a machine-unique challenge value. (This process is sometimes called "fingerprinting.") This challenge uniquely identifies a particular machine, and because of this, when it is used as part of authorization generation it can "lock" both your software and its InterLok authorization instructions to a particular computer. Software authorized using challenge/response cannot be moved to another machine unless a new response for that machine is obtained. Because of this, a challenge/response locked application cannot be distributed freely by pirates.

InterLok's "active demonstration" features (described in a moment) are controlled through challenge/response authorization. This locks the demonstration environment to a particular machine and allows tight control over the number of program launches or elapsed evaluation time.

When you use challenge/response authentication to control your application, your customer provides (by phone, fax, e-mail, etc.) the challenge that the InterLok "wrapper" locking your application has generated. You enter this challenge along with your authorization instructions into the InterLok Satisfaction program, which generates a response. You then give this response to your customer, who enters it into the their copy of your software.

InterLok distinguishes between demonstration challenge/response authorization and "final" challenge/response authorization, which is when a locked application is purchased and becomes fully authorized.The essential difference is that a challenge created by InterLok when a locked application is in one of the demonstration modes has a random component added to it, so that a different challenge is generated each time a previous demonstration challenge is successfully answered.

This variation keeps a user from entering the same response over and over to extend their demonstration period. A "final" InterLok response unlocks the application (on a particular machine) for all time, and can be used as a response to whatever challenge InterLok may generate.

Because InterLok challenges are associated with a particular hard disk, a hard disk with an InterLok'd application on it can be moved from one computer to another and the application will continue to run. InterLok takes this convenience even further by not requiring the locked application to be on the same hard disk that was authorized. If the hard-disk that was originally authorized is available anywhere on the user's machine, InterLok will find it and allow your application to run. In this way the hard disk functions in the manner traditionally associated with hardware-key "dongles", but at a much lower cost. Your users have no restrictions on which hard disk volume they place their InterLok'd applications. They can reorganize and move their applications from disk to disk at will. As long as the disk drive originally used to generate the challenge is available, everything will simply work.

Now that you're familiar with the mechanics of InterLok authorization, we can take a look at the features this facility provides. In the following diagram, the black boxes show the various modes an InterLok'd application can be in. Challenge/response authorizations are shown in red, serial number authorizations are shown in blue, and mode transitions caused by InterLok itself are shown in black.

An application locked with InterLok can arrive on an end-user's machine in one of three different states, shown on the top left side of the diagram. These states are Unauthorized Application Mode, Active Demonstration Mode and Unlimited Demonstration Mode.

Software in Unauthorized Application Mode comes with no "money in the meter" so to speak. Though locked by InterLok, it has not received authorization instructions that allow it to run. This means an end-user running this software only receives a "please register this software" message and must check in with you for authorization before they are allowed permission to use your program.

Scenario One: (Challenge/Response) You ship your software on floppy or CD-ROM to customers who have already paid for it, but you want to be sure they can't copy the software from machine to machine or give copies to friends. By shipping an unauthorized application, the customer must contact you to receive a challenge/response authorization that will put the application into authorized application mode and lock it to their system. (A subtle point is that users who have bought shrink-wrapped software often want to be able to run it the moment they install it, no doubt at 2AM on a Saturday morning, and having to call you for authorization is not going to make them happy. Setting up a short demonstration period can solve this problem. See the classic trialware scenario below.)

Scenario Two: (Serial Number) You distribute an application and its promotional materials from a web site to anyone who cares to download it. By reading the promotional material (or executing promotional software), your customers decide they want to buy a license for the program. They contact you by phone, fax, mail, e-mail or web site, pay for the license, and you issue a serial number authorization that activates the software and puts it in serialized application mode. From this point they are not bothered by InterLok any further.

An application that arrives in Active Demonstration Mode is allowed to run for a developer-specified period of time to give potential customers time to evaluate the software to see if it meets their needs. This is the classic "trialware" scenario, where you get the benefits of shareware-style distribution coupled with some enforcement to insure you actually get paid.

Active Demonstrations can be allowed to run for a specified number days or for a specified number of launches, or a combination of both. InterLok ties these demonstration limits to a particular machine, but the current demonstration state is not stored with the locked application. This means a user cannot repeatedly download an evaluation version of your software over and over to continue using it indefinitely. Once the demonstration period is over for an application, it is over, no matter how many "fresh" copies of the application subsequently arrive on a user's machine.

An Active Demonstration can also be set to expire on a fixed calendar date. This facility is provided as a simple way to expire distributions of beta software that have been challenge/response locked to a particular machine. Such software often runs for 30-60 days, only to be superseded by another beta release or final version of the product. (InterLok's own beta test releases were locked in this way.) Unlike date limited serial number authorizations, this expiration date can be defeated by setting the clock back. (So if the next beta version of software turns out to be late -- impossible, we know, but... -- your testers can set their clocks backs and continue working with the software.)

If a user discovers the Active Demonstration period is too short for a full evaluation, they can contact you either during the demonstration or after it has expired and you can remotely enable another Active Demonstration period using challenge/response authorization. (This is shown by the red arrow that loops back to the Active Demonstration mode in the diagram above.) You can grant extensions of the demonstration period as many times as you wish. You can also change the demonstration limits each time you re-enable the active demonstration mode. (For example, to make the number of days the program can run shorter or longer.)

When an Active Demonstration expires, InterLok automatically transitions the application into Expired Application Mode. If the developer has specified "nagware" as an InterLok option for this application, the application is still allowed to run, but each time the user runs the program a reminder is displayed indicating that the demonstration has expired and that it is time to register the program. If the nagware option was not specified, the same sort of message is displayed, but the program immediately quits if the user does not provide authorization. As with all InterLok messages, these displays can be easily customized by the developer.

Scenario: (Classic Trialware) You lock an application with InterLok and distribute it configured in Active Demonstration mode with a 30 day time limit. The user gets to run the software for 30 days. As the end of the 30 days approaches, warning messages appear indicating the time limit is expiring. If the user contacts you (and buys a license), you provide either a challenge/response or serial number authorization, deactivating the demonstration and putting the application into the authorized or serialized states. Once fully authorized in this way, the user is no longer bothered by InterLok. If the user does not contact you, at the end of the 30 days the demonstration expires. If you turned on "nagware" the user is reminded the demonstration is over and that they should register, but is still allowed to continue. If you have not turned on "nagware" the user is told the demonstration has expired and is given the opportunity to provide authorization information. If they do not, the application quits.

Finally, InterLok'd applications can be shipped in Unlimited Demonstration Mode. An application shipped this way is considered to be a demonstration by InterLok, but the demonstration period never ends. If you turn on the "nagware" feature with an unlimited demonstration, you have the classic shareware model where a developer-defined "please pay for this" message is displayed every time the program is launched. With nagging off, you can create software that InterLok considers to be a demonstration, but which does not bother the user with any messages. Combining this mode with the InterLok Application Program Interface (API) and some custom code, it is possible to disable features of your program during the demonstration period. This is sometimes called "feature limited demoware" and we will return to this topic in the PACE Interface section of this document.

When a demonstration period has expired, or a locked application is otherwise unauthorized, InterLok presents dialogs requesting serial number or challenge/response authorization. The InterLok wrapper can also be "told" to display its authorization dialogs by having the user hold down special developer-defined key sequences while the program is launching. This allows "on the fly" changing of authorizations -- to extend a demonstration period, for example -- with no programming required by the developer. Finally with custom programming, the PACE Interface can be used by a developer to invoke the authorization dialogs at will. This can be used to implement a menu item or other UI that will directly invoke the authorization system.

Registration Capture

When you apply InterLok to your application you can also request that InterLok capture and record customer information, such as the user name, company name, address, phone number, e-mail, etc. This information can be retrieved programmatically by a locked application using the InterLok API. This allows registration information to be displayed in an application's "about" box, for example. You can choose what fields of registration information you wish to collect or you can choose not to collect any registration information at all.

Localization

All of the common messages InterLok displays to an end user are easily specified by the developer when the lock is applied to the application. For developers who wish to radically change icons, dialogs and other interface elements, modifying an ordinary resource file is all that is required.

Do you want to set a few options and use point-and-click to wrap your application with an InterLok? Fine. Want to write custom code to tightly couple InterLok to your software and implement advanced features? Fine. InterLok lets you do both.

The InterLok protection generator, Master Maker(tm) is used to apply a lock to your application. For example, setting up a 30 day demonstration period involves setting a few simple fields as shown and then pointing Master Maker at your finished application and telling it to apply a lock.

The InterLok authorization generator, Satisfaction, uses the options document from Master Maker to generate responses appropriate for a particular locked application.

You can also open an existing options document with Master Maker and use it to InterLok a later version of your software. In this way subsequent releases can be distributed that will respond to the same authorizations from Satisfaction. You can have multiple versions of your program in circulation and they can all be authorized in the same way. You simply don't have to worry about version related authorization issues. Further, a user can download a new version of your software in the middle of an evaluation period and it will simply work with no disruption in the demonstration experience.

On the other hand, the new version of your software may be so revolutionary you want to force all of your customers to "check in." In this case, creating a new options document (with appropriate options) will cause this to happen.

While point-and-click InterLok locking is an effective solution in a large number of situations, there are always developers who want to go further and use the lowest levels of InterLok protection directly. InterLok provides an API called the PACE Interface that protected applications can call into to provide advanced features.

We have already alluded to some of the features this API makes possible, including displaying customer registration information in the "about" box and providing a menu choice to directly invoke the InterLok authorization subsystem. You can also repeatedly check for the presence of InterLok and your program's authorization. Doing so makes InterLok protection extraordinarily difficult for a pirate to defeat.

The PACE Interface also allows you determine that your program is in unlimited demonstration mode (which is called a "smart demo" in the interface API). As we mentioned above, using this knowledge you can implement "feature limited demoware" -- that is, turning off features until the application is fully authorized.

Scenario ("Feature Limited Demoware") You ship your software in Unlimited Demonstration/SmartDemo mode and have disabled a feature, say saving files, in your application. As long as PACE Interface reports you are still in "smart demo" mode, your program keeps file saving turned off. When a customer purchases the program, you use serial number or challenge/response authorization to fully authorize the program. Now the PACE Interface will report the application is fully authorized and you can turn the file saving feature on.

What if a big customer won't buy the program unless they can save some files to be sure it actually works? No problem. You can use challenge/response authorization to put the program in active demonstration mode, for say, 10 days. When the PACE Interface reports this has happened, you turn file saving on. When the 10 days are up, InterLok will automatically transition your application back to unlimited/smart demonstration mode. Your code will detect this and turn file saving back off. (This is the upward pointing black arrow in the Interlok mode diagram above.)

For developers that require further control of entire sets of features (For example, a light, standard and professional version of a product, with different features and all remotely upgradeable) our InterLok Pro product provides this as well as high-security encrypted storage for arbitrary developer data.

Finally, we'd like to note that the ease-of-use provided by InterLok can sometimes hide the fact that InterLok is the culmination of over 14 years of software protection expertise. While we can't go into the details in a public document such as this, the InterLok system employs a variety of field-proven anti-hacker protections such as multiple encryption, comprehensive self-checking and debugger killing algorithms. All of this makes InterLok extremely difficult to defeat or remove.

The challenge/response and serial number authorizations use a variety of cryptographically secure technologies to ensure their robustness, including algorithms from RSA Data Security and Internet standards such as S/Key.

This "under the surface" technology is as large a part of the InterLok system as the many features already described here. We wish we could say more about it, but we can't. Trust us. It's in there, it's very good, and it works.