Open Platform Initiative for Multimedia Access
OPIMA Applications ver 0.1
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 (firstname.lastname@example.org).
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 :
OPIMA reserves the right to modify the contents of this document according to its procedures for technical and without notice. OPIMA makes no claim as to the business significance of the applications and services considered in this document.
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.:
- stock exchange information
- traffic information
- GPS information
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.
|Services: Electronic Program Guide|
|Secure code loader: Secure code loading sourced from MPEG Transport stream or from smart card|
|API-1: APIs to and management of smart card access, descrambling, ..|
|Sk1: CA system smart card||Sk2: descrambler||..||.||Skn|
|OPIMA VM: ensures security of Sksinstalation & operation occording to business rules.|
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:
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 (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 Ski. 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:
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.