Java and Cryptolopes

As we saw earlier, Java applets may be considered to be assets, pieces of intellectual property which need to be protected from prying eyes. We discussed the threat from decompilation attacks and how you might attempt to foil decompilers.

There is, however, another way in which applets may have value which must be protected.

Most Java applets you encounter on the Web are available to you free of charge. Usually the Web page owner uses them to make the page more attractive or to provide a function he or she wants you to use - such as an investment planning application intended to help sell you a mutual fund. Sometimes, however, it is you who want to use the applet: an applet might be a particularly good game, or a useful spreadsheet that you want to use. In this case the applet owner may wish to charge for the use of the applet.

If I am the applet owner, I have three main obstacles to overcome:

  1. I would like to send my applet to you in a protected form, such that nobody - including you - can execute it. In addition, I would like to send you information about how much I intend to charge you for its use, what it does and other such information (technically known as metadata ).
  2. I must be able to accept some form of payment from you in order to allow you to use my applet. Ideally, you should be able to pay different amounts depending on how you wish to use it. For example, I might charge a single sum for unlimited use, a different sum for a single use and yet another sum to use the applet for a specified period of time.
  3. I must be able to grant you the usage rights for which you have paid without allowing you any additional rights and particularly, without allowing you to give access to your friends (who haven't paid me for the privilege).

Of course, I could encrypt the applet code and sell you a key which would allow you to decrypt it and this would meet requirement 1 and some of requirement 2. It would fall short of requirement 3, however, since once you have decrypted the applet class files, you would be free to distribute them among your friends. In addition to this fundamental flaw, there is something deeply unsatisfying about the payment model. It lacks subtlety and flexibility: you either have the code and can use it as often as you please, or you don't.

In fact, the third requirement proves to be the most difficult to satisfy and it is this requirement which is addressed by IBM's Cryptolope Live! product, the latest evolution of Cryptolope technology.

Cryptolope History

Cryptolopes were first designed (at the IBM laboratory in Falls Church, Virginia) to address the general issue of charging for intellectual property on the Web, and on other networks. Like many other Internet security ideas, they have their roots in cryptography. If you access my Web page to download some chargeable material (which could be a magazine article or a detailed weather forecast just as easily as it could be an applet) and I send the material to you, I shall want to send a bill later. But how do I know whether you ever received it?

The Internet does not guarantee delivery, far from it, and if you say you never received it, how am I to know whether you are lying, let alone prove that you are lying. We can use SSL to authenticate both ends of the dialogue; that is, you can be sure that the Web page is really mine, and I can be sure that the browser is really yours. The use of public-key certificates ensures that. But it does not tell me that the delivery of the chargeable material happened without problems, and it does not give me anything that proves that you requested that particular chargeable material. Cryptolopes can give you both of these by the simple expedient of sending the material in encrypted form. When you request a decryption key, you confirm that you have received the material and that you are willing to pay for it.

Originally, Cryptolopes focused primarily on the delivery and payment mechanisms for content. Ultimately, whatever the asset, be it a font, some HTML, an audio or video file or even an entire application, it needed to be extracted from the protective shell of the Cryptolope and handed to an application which would render it. This exposed the asset to the risk of copying.

This sort of problem has affected copyright material for centuries, and people still manage to make money out of writing books and recording music. This is because honest citizens and respectable companies don't make a habit of massively infringing copyright - they want to have legal original copies. So does it matter? Well, yes, to some extent it does.

The difference between a book on paper and a book in HTML is that a photocopy of the paper book is much less usable than the original; a copy of an HTML book is identical to the original. A tape copy of a music CD is less clear than the original; a copy of a digital audio file isn't. Digital copies are perfect copies, and with the prevalence of Internet access, it is possible for a single unscrupulous vendor to create and sell many perfect copies of an original, all over the world and even from a server in a country with less restrictive copyright laws.

Today: Cryptolope Live!

Cryptolope Live! is a major evolution of the original Cryptolope concept. Whereas early Cryptolopes focused on content commerce, Cryptolope Live! emphasizes the process of presenting the content, installing the content, metering the content use and interacting with the end user. In short, it addresses requirement 3 above.

Cryptolope Live! deals in Cryptolope objects. These are a combination of content, scripts and extensions. The content (part) is the payload of a Cryptolope object and may be Java classes, digital audio or any type of digital content. A Cryptolope object may contain a number of parts all of which are held in a folder structure, similar to a filing system. The scripts are a small set of business rules associated with each part and folder which determine what the Cryptolope object will do in terms of rendering content, billing the user, metering usage or whatever. The extensions are pure Java classes which extend the capabilities of the scripting language when more complex functions are required (see See Cryptolope Live! Objects ).

 
Cryptolope Live! Objects

Scripts are written using Cryptolope script, a simple yet powerful programming language based on ECMAScript, a standard scripting language defined by the European Computer Manufacturers' Association and based on JavaScript.

The main component of Cryptolope Live! is the Cryptolope Player. This is written in Java and runs the Cryptolope objects. There are several parts to the Cryptolope player as shown in See Components of the Cryptolope Live! Player .

 
Components of the Cryptolope Live! Player

The Cryptolope player first loads the Cryptolope object and validates its structure. If the Cryptolope object has been digitally signed then the certificates are presented to the user who reviews this information and approves it. Finally, the Cryptolope object is authenticated and the main script is loaded and executed.

The Cryptolope Player implements a Sandbox and security manager, exactly like the JVM (indeed, it uses a Java security manager class). Thus, Cryptolope objects are prevented from accessing local storage, running native code and all of those restrictions which we saw earlier applied to unsigned applets. If this process seems familiar, then you should not be surprised. Any resemblance to the Java security architecture is purely intentional.

The script itself is responsible for implementing business rules which may require providing payment information for the content prior to making it available (decrypting the content) to the end user.

Another implementation may simply require authentication of the end user (for example, via a user ID and password) prior to rendering the information. The rules may only authorize the end user to view the content, or they may authorize saving it to a file, or printing it.

The Cryptolope Live! product is delivered with a set of scripts and extensions that let you write and customize your own information commerce system for the distribution of, and payment processing for, digital content. The provided scripts allow your enterprise to build a Cryptolope object and encrypt one or more documents within it. This system flow proceeds as follows:

  • You specify if the content can be viewed, printed, or saved to file for specified prices, and whether the content within the Cryptolope object ever expires.
  • When an end user receives a Cryptolope object (via the Internet as a Java applet or to be run as a Java application) the Cryptolope object is run by the Cryptolope Player.
  • The Cryptolope Player executes the scripts located in the Cryptolope object and presents to the end user information about the documents they may select to purchase (for example, an abstract, authoring information, or a thumbnail diagram of a larger picture that is encrypted in the object), along with the information the end user requires to make a purchase decision.
  • When the end user chooses to purchase the content, the script then presents a dialogue to request credit card payment information. This information is sent to a clearing center run by your enterprise or trusted third party. The clearing center works with the Cryptolope Cashier which can link to third-party payment systems.
  • Upon completion of the credit card transaction, the clearing center sends the appropriate document key for decrypting the purchased document content back to the end user's Cryptolope Player. Then the application decrypts the document and renders the purchased content in the trusted viewer.
  • After the content is displayed, the end user can elect to print or save the document if these options have been enabled.

When a Cryptolope object is loaded, the following actions occur:

  • The Cryptolope object itself is evaluated for authenticity based on the digital signatures it may contain.
  • If the Cryptolope object appears not to have been altered, then the loader creates the Cryptolope object model, representing the structure of the object and the elements comprising it.
  • The object model calls the Cryptolope Script interpreter and starts running the script in the Cryptolope object.
  • The scripts then control the actions of the Cryptolope object on the end user's system. The scripts can call extensions (Java class files either internal to the Cryptolope object or external on the user's CLASSPATH) or can make available script functions that an extension can call directly.

Cryptolope Live! also includes the Cryptolope Builder. This is a simple mechanism for creating Cryptolope objects. In addition to the development tools, the IBM Cryptolope Live! system includes subsystems for security-rich content delivery and content commerce. They are:

  1. The IBM Cryptolope Clearing Center, along with extensions for Cryptolope objects which allow them to connect to and communicate with the clearing center.
  2. The IBM Cryptolope Cashier which is a gateway to a payment mechanism from the clearing center, allowing for the all important collection of money!

Example Applications

Imagine that you have developed the ultimate killer app. Perhaps it is a Java based streaming video viewer which tunes into an Internet news channel. You want to sell access to the channel on a pay-per-view basis.

First you embed your Java class files in a Cryptolope object. Then you write a simple script which charges the end user in blocks of five minutes, calls the clearing center, obtains a decryption key, decrypts the classes and executes them. When the time limit is up, viewing is interrupted by the script which prompts for more credit for the next five-minute period.

You now have a totally flexible, secure product which will run anywhere, either stand-alone or inside a browser. You can give it away to your customers who will be charged as they use it. If they give copies to their friends, this is fine since their friends will also be charged as they use it; thus, now your customers have become a distribution channel for your software and they even pay you for the privilege!

Tomorrow

This is only a first step. In the future, Cryptolope technology may be tightly integrated into the JVM rather than requiring the layer of indirection provided by Cryptolope Script. Then Java classes rather than whole applications or applets could be distributed on a pay-per-use basis.

Vendors of class libraries or software components will be able to distribute their code widely without charging developers who use it and without having to draw up complex licensing agreements. They will be able to rest easy, safe in the knowledge that they will be paid in full each time an end user uses their libraries, regardless of the product those libraries are embedded in.