OPIMA Applications ver 0.1

1. Introduction

The following describes the application areas made possible by the "The OPIMA environment". The OPIMA environment, as described in the OPIMA Specification Document, is targeted at providing a consumer the ability to legally acquire and consume multi-media services on a worldwide basis. The documents follows the approach of first introducing the OPIMA framework. The following chapters apply this framework on a number of specific, example, application areas.

1.1 Who should read this document

Parties and entities interested in applying the OPIMA environment should read this document that introduces some possible application areas for the concepts behind the OPIMA approach. It should be mentioned to the reader that the list of application areas mentioned in this document is neither complete or exhaustive. Comments are welcome and should be addressed to: Dr. Leonardo Chiariglione (leonardo.chiariglione@cselt.it).

1.2 Contents of the document

The document contains 5 chapters. The first is this introduction. The second lists some examples of the variety of services and applications that are made possible by the OPIMA technology. The third introduces the OPIMA framework. The last two are two use cases :

• Broadcast Application
• Audio On Demand Application

2. Services and applications made possible by OPIMA

The introduction of digital technologies has not yet substantially affected the way applications and services are offered. Digital television provides a wider choices but the offer paradigm is unchanged. Music is being offered on the Web but most instances are of music offered for free.

Digital technologies, however, have the potential to enable a much richer offer, e.g.:

1. Subscription TV/Audio
2. Pay-Per-Use
3. Near Video-on-Demand
4. Audio/Video-on-Demand
5. Services that add value to those mentioned above – for example, paid-for Electronic Program Guides and other such services
6. On-line multimedia services – such as consuming services through the Internet
7. Free TV/Radio
8. Targeted advertising – The user obtains permissions/credits in return for viewing advertising content
9. Rent-to-Own – After paying n times, one can use the content for free (If n = 1, this becomes the ‘Pay-One-Time-Fee’ model)
10. Coupon Services – The user gets a ‘token’ which may be used for using content, getting discounts, etc. The token can take many forms, for example a piece of software, a digital key, a smart card
11. Information services – The content being obtained is not necessarily audiovisual. A few examples:

• stock exchange information
• traffic information
• GPS information

1. Games (single or multi user)
2. Software distribution – It is believed that this is very similar to any other content distribution
3. Home shopping, home banking, gaming – Services in which transactions play a role. Note that there is a clear connection between a television service (advertising) and home shopping
4. Auditing / Polling / Voting – This means that a service provider can gain knowledge about the number of users accessing services and their degree of appreciation

2. The OPIMA Framework

3. Broadcast Application

This section describes the broadcast use case of the OPIMA model. We will take MPEG-2 pay-TV as an example of a broadcast service. The authorization to consume is controlled by a conditional access (CA) system.

In this case the OPIMA client is a set-top box (STB). The STB is a generic device, that is independent of any particular CA system. The STB is instantiated for a particular CA system by (1) inserting a smart card for that CA system and by (2) downloading CA system specific software into the STB in the SKs.

By this extension the OPIMA VM is capable of grating acess & descrambling the broadcasted content.

An example service is an Electronic Program Guide (EPG). An EPG allows end-users to access services and to retrieve service information. The main CA related EPG functions are to (indirectly) initiate service descrambling and to allow retrieval of CA information (e.g., on the availability of entitlements).

The SKs are CA systems. It is downloaded and/or inserted into the terminal and implements the functionality that is specific for a particular CA system, for that reason it can not be embedded in the generic part of the OPIMA client. The main function of the resulting CA system (smart card and downloaded CA system code) is to control the access to content to be consumed. This requires among others:

• Translation of requests to descramble a service into primitives defined by the secure kernel API and by APIs that give access to other STB functions.
• Retrieval from the MPEG transport stream of entitlements (i.e., rights to access a service) and subsequent processing. This will also require access to the lower level APIs.
• Retrieval and processing of CA related information. Translation of requests to retrieve information from the CA system into primitives defined by the secure kernel API and by APIs that give access to other STB functions.

There can be several sources for the code to be downloaded. The more likely sources are the MPEG transport stream (e.g., on the basis of the DSM-CC protocol) and the CA system smart card. The secure code loader implements the downloading protocol. As far as security is concerned the following is required:

• The secure code loader ensures the confidentiality, integrity and authenticity of the downloaded SKson the link between the code source and OPIMA client. This is required to protect the client from fraudulent CA systems and from attacks on the code while downloading.
• It shall be possible that the smart card controls (authenticates, decrypts, …) the applets loaded by the secure loader.

The secure code loader (with the help of the smart card) also implements the management of downloaded code. There shall be a procedure that initiates loading and removal of the Sks. This may have security implications and has to be designed carefully.

The secure kernel API provides access to the security related functions Sk_i. In general, these functions can either be resident in the smart card or secure storage of the STB or the STB can be upgraded with these functions. An example of an upgradable function Ski is the smart card of a particular CA system. An example of a resident function Ski is the descrambler for scrambled MPEG-2 content. The secure kernel API also takes care of the management of function upgrading, e.g., like the OpenCard framework does.

Note that the downloaded CA system will also require access to other STB functions than the security related functions provided by the secure kernel API. Examples of such functions are section filtering, SI information, user interface.

The secure code loader provides security to protect the STB from malicious downloaded code. The OPIMA VM provides important security functions:

• The OPIMA VM should ensure the confidentiality and integrity of the CA system code downloaded into the STB. This code should be protected from hackers. An example is the verifier functions that secure the communication between smart card and STB. These functions require encryption algorithms and encryption keys. The OPIMA VM ensures a sufficient degree of security for these items by the AVP & SAC.

5. Music On Demand Application

An OPIMA box is purchased from a service provider (SP) A. It comes with a pre-installed SK that allows it to access services provided by A. The box is turned on for the first time. The MOS boots, the system is initialised loading fundamental trust primitive processes (AG, AV, SAC, SCL), and some data (e.g. some public/private keys and possibly other necessary secrets) may be stored in protected memory. These are used, among other things, to facilitate mutual authentication between the SKs and the OPIMA box.

As part of the boot the SP A button appears on the screen. Clicking the button a default application provided by SP A is loaded. The application shows a screen with two buttons. Clicking the first one gets 5 seconds of music streamed from the SP A server, clicking the second the application requests the download of the music. This is encrypted and comes with a set of rules which describe how it can be used. In order to access the music the user must have the rights (key etc.) to access it.

There is a protocol (TBD) that takes advantage of a SAC between the OPIMA box and the SP A server that carries keys and rights expressions. Application A interacts with the SK of SP A and/or the OVM to interpret the rights expressions and present the business model to the user. The user makes a selection that is communicated to the SK which enforces the rights. In another scenario the OPIMA box may need to communicate with the SP A server. And now the application requests decryption and release of music to the application's decoder. In one case decryption happens in the SK. In a typical hardware-based STB the SK instructs the decryption unit to decrypt.

In case the music is streamed from the server and key updates are desired the key updates could be transmitted via the SAC from server to client. Those key update messages may be interpreted by the SK and then passed to the decryption engine.