Using KPs for Intellectual Property Rights Management

This demonstration illustrates some mechanisms that could be
used to enforce intellectual property rights in the Knowbot Operating
Environment. A full-fledged enforcement system would build on security
and electronic payment infrastructure that is not part of the current
KOE implementation. There are many variations on this theme
that are being explored with ongoing KOE work.

In the demonstration, Knowbot Program (KP) couriers manage
intellectual property rights. The basic scenario for the demo is this:
A user wants to select, preview, and possibly purchase high resolution
images (of bass guitars, of course). The user launches a KP that
migrates to the image repository, retrieves a list of available
images, and ask the user to select an image. The image has terms and
conditions associated with it and several KPs participate in a
negotiation process that guarantees the terms are met.

Two Knowbot Services Stations participate in the transaction. The
first service station is the user's home KSS, which receives
the KP when it is first launched and to which the KP ultimately
returns. The home KSS provides two services, one which allows the KP
to interact with the user and the other which can display images in a
window on the screen.

The second KSS provides a Kahn-Wilensky
style
repository that vends images. Each image is available in a free
low resolution form and in a pay-per-view high resolution version. The
repository allows uncontrolled access to the low resolution image, but
requires that specific terms and conditions be met for use of the high
resolution image. These terms are negotiated by the user via a KP.

The easiest way to get the demo set up is to use the koeboot.py script. You
will need to start the a worldroot and two service stations, one with
an arbitrary name (this document uses the named "anthem") and one with the name "imagerepo." You should also start a visualizer.

The "anthem" KSS must be running two services, simpleio
and the Player. The "imagerepo" KSS must be running the
ImageRepo service. This section shows how to configure
anthem and imagerepo. See Configuring
Plugins for detailed instructions on configuring plugins.

Edit the file $KOSROOT/config/plugins.anthem. It should
contain the following lines:

Next, edit the boot configuration file
$KOSROOT/config/boot.$LOGNAME, where $LOGNAME is the value of
the $LOGNAME environment variable (or $USER if $LOGNAME doesn't
exist). Put the following lines in the file:

[Visualizer]
enable: 1
[KERNELS]
-: %(hostname)s imagerepo

Once you've edited these files, start the demo by running
$KOSROOT/tools/boot/koeboot.py You can shut the demo down
by using the $KOSROOT/tools/boot/koehalt.py script. Be sure
to pass in the --all option if you want the visualizer and
worldroot to be shut down as well.

The demo begins when you launch a courier KP --
$KOSROOT/demos/rightsmgt/rightsdemo.py -- to your home KSS. The
courier KP locates and migrates to the image repository. At the image
repository, the KP requests a list of all available images. Then the
KP returns o the home KSS and asks the user to choose one of the
images to retrieve.

After the user has chosen an image, the KP then migrates back to
the repository and retrieves the chosen image. It also retrieves the
image's metadata and two disseminations (version) of the image. One
dissemination is a a thumbnail (a low resolution, free
image) and the other is a high resolution image.

Once the KP returns to the home KSS with the two disseminations, it
passes them to the ImagePlayer service, which attempts to display the
images on the screen in separate windows. Since the thumbnail
requires no conditions for its use, it is successfully displayed on
the screen. However, the high resolution image does require that some
conditions of use be met, and so it cannot be displayed on the screen
at this time. Specifically, the image data is encrypted and
technically not even image data!

The KP knows that terms and conditions must be negotiated for the
high resolution image. So when it was at the image repository, it
retrieved some metadata for the digital object. The metadata
includes the terms and conditions for use of the object. In this
demo, this metadata contains the price of a
single use of the high resolution image. Once the thumbnail has been
displayed, the KP will ask whether the user wants to spend the money
to purchase a use of the high resolution image. When the answer is
yes, the KP will clone itself, and the clone that will make sure that
the conditions of the image's use are satisfied.

The clone carries a transaction specific ticket and a
payment. It returns to the image repository, makes the
payment, and receives a decryption key. Then it returns to the home
KSS to rendezvous with the original KP.

This demonstration is intended to show how Knowbot
Programs might enforcement intellectual property rights -- not how to
carry out payment transactions over the Internet. As a result, the
demonstration implementation does not include a real payment
system.

The courier KP, which carries the encrypted image, and its clone,
which carries the decryption key, do not have enough information to
use the image. A third KP, which carries the decryption
algorithm is needed. Once the image repository receives
payment, it launches this third KP, called the decrypt KP to
the home KSS.

Once all three KPs show up at the home KSS, they rendezvous. The
courier KP passes the encrypted high resolution data to the decrypt
KP, and the clone passes it the decryption key. The decrypt KP
combines the two using its algorithm, and displays the decrypted image
by using the ImagePlayer service. The demo repository currently
implements a "pay once, play once" policy. So once the image is
displayed, all three KPs exit and the demo is finished.

The decrypt KP serves several purposes.

It partitions the protected
intellectual property into three parts, the encrypted data, the
decryption key, and the algorithm used to combine the data and the
key. Any misuse of the data requires that all three KPs must be
captured.

The decryption algorithm can be made subtly different for each
transaction, because it is contained in a separate KP. This variation
makes replay attacks more difficult.

Because the image repository creates and controls the
decryption KP, which combines the encrypted data and the key, the
image repository also controls the policy by which the image can be used.
The image repository can enforce the policy of "one payment, one
use" or "one payment, ten uses," or "one payment, unlimited uses
within a month." The decrypt KP, acting as the agent of the
image repository, enforces this policy.

You can run the demo in interactive mode or in auto-pilot mode.
Auto-pilot is useful if you just want to verify that
everything's working correctly, but
running the demo interactively is the best way to see the demo in
action. Interactive mode is the default.

One of the first things the KP will do is contact the
simpleio service on the home KSS. This services opens a
talk-like window used as I/O for the KP. The window
is shown in Fig. 2.

Figure 2. I/O window for interacting with the KP

The KP asks questions of the user in the upper half of the window,
and the user enters responses in the lower half of the window. All
questions take a numeric response, which is a choice from the
displayed list. In Fig. 2 the KP is waiting for the user to choose
which KSS has the image repository. The status line between the two
halves indicates that the KP is blocked reading input. The lower
window shows a prompt and a cursor where new input is entered. The
buttons on the bottom of the window clear either the input (bottom)
half or the output (top) half, or quits the I/O window. For numeric
response questions there's a secret escape hatch. Entering
zero to any choice question exits the KP.

Thumbnail (free, unencrypted)

High resolution (encrypted)

Figure 3. Two disseminations

In this case, you will enter the number of the imagerepo
KSS (which may be different, depending on your home KSS name since
they are listed here in alphabetical order). When you enter the
number and hit return, you will see the KP migrate to the imagerepo
and return, then display a list of image descriptions. Choose the
image of the bass guitar you want to view and hit return. The KP will
visit the imagerepo and return with two disseminations. The KP will
pass both to the ImagePlayer service on the home KSS, which
will attempt to display them as if they are images (as shown in Fig.
3).

You'll notice that the ImagePlayer service cannot display the
high resolution image.

Figure 4. High resolution image, decrypted

At the same time, the KP has retrieved metadata about the image,
describing the amount of "money" that must be spent to decrypt the
high resolution dissemination. In the simpleio window, it
asks you if you want to spend this money. If you answer yes, the KP
will clone itself and the clone will prepare to migrate back to the
image repository.

An intermediate step is injected into the demo.
After the courier KP has cloned itself, but before the clone migrates,
the clone will ask you to hit ``Enter''. This gives the demonstrator
time to describe what is going on in the demo.

The clone will migrate to the image repository, conduct the e-cash
transaction (a truly virtual transaction), receive the
decryption key, and return to the home KSS with this key. At the same
time, the image repository KSS will launch the decrypt KP back to the
home KSS. When all three KPs arrive at the home KSS, you will be
asked to hit Enter again. When you do this, the
courier KP will pass the encrypted dissemination to the decrypt KP,
and the clone will pass the decryption key to the decrypt KP.
The decrypt KP combines this data and displays the image using
the ImagePlayer service, as shown in Fig. 4.

Once the high resolution image has been displayed, all three KPs exit
and the demo is finished.

The demo can also be run in an autopilot mode that is essentially the
same as the interactive version except that the courier KP never uses
the simpleio service and no questions are asked of the user.
At each decision point, the KP makes a default choice.

When it looks for the image repository, the KP always chooses the
KSS named imagerepo. The courier KP always chooses a digital
object at random, and always assumes the answer to any question is
yes. At the end of the demo, the three image
windows will be shown and all KPs will exit.