OPIMA

Digital Television Achieves Maturity

Leonardo Chiariglione
CSELT, Italy

Leonardo.Chiariglione@CSELT.IT

1. Introduction

Digital television is happening in many countries and business environments. Its diffusion, however, is not happening at the pace many had predicted in the past and many are expecting now. The main reason lies in the proprietary nature of set top box (STB) access control (AC), the technology that allows a Service Provider (SP) to permit access to content only to those who have acquired the necessary rights. This situation has produced unreasonably expensive STBs, market segmentation with a reduced number of customers in each segment, heavy subsidisation of STBs or commitment of substantial resources to lease STBs on the part of SPs, regulatory interventions in certain countries where efforts to achieve a larger audience on the part of SPs are thwarted by regulators as anti-competitive.

This was probably unavoidable until a few years ago because of technology limitation. Fortunately it is now possible to develop open specifications that will allow users to navigate, select, pay and view the offers of any SP.

The Open Platform Initiative for Multimedia Access (OPIMA) is a recently-established industry consortium with the goal of developing such open specifications by September 1999. A Call for Proposals (CfP) has been issued in May (http://www.cselt.it/ufv/leonardo/opima). This requests interested parties to submit proposals of technologies that are believed to enable the attainment of OPIMA goals. Deadline for submissions is 31^st August 1998.

This paper describes the hooks provided by the MPEG-2 standard for access control (section 2.), its limits (section 3.) and the solutions developed so far, the new possibilities offered by technology (section 4.), the requirements that an open solution brings forward (section 5.) and the OPIMA reference architecture. Sections 4. to 6. draw heavily from the said CfP.

2. MPEG-2 and its legacy

Three and a half years after MPEG-2 reached International Standard status it may be time to have a dispassionate look at the practical results of the international collaborative effort that produced such a renowned standard.

MPEG-2 Video is capable of compressing the 166 Mbit/s of ITU-R 601 to a few Mbit/s. The MPEG-2 Video verification test campaign has proved that at 6 Mbit/s MPEG-2 pictures are subjectively equivalent to composite video in the studio. The same tests has proved that at 9 Mbit/s MPEG-2 pictures are subjectively equivalent to component video in the studio These result apply for Constant Bit Rate (CBR). Even more interesting results can be obtained by the use of Variable Bit Rate (VBR) coding, even though publicly available results produced by independent bodies are not known.

MPEG-1 Audio, used in many digital television systems in practical use, is capable of compressing the 1.5 Mbit/s of a stereo channel sampled at 48 kHz down to 256 kbit/s with subjective transparency. MPEG-2 Audio Backwards Compatible (BC) mode compresses 5.1 sound with good quality down to 320 kbit/s, while MPEG-2 Advanced Audio Coding (AAC) compresses a stereo channel at 128 kbit/s and 5.1 sound at 320 kbit/s transparently.

MPEG-2 Systems provides multiplexing and synchronisation of audio and video in addition to a host of other functionalities. The Transport Stream version provides physical layer adaptation for transmission over a hostile environment while the Program Stream, unsuitable in general to transmission over an error-prone channel, provides other features such as editability.

In other words MPEG-2, in its Transport Stream version, provides the one-stop shop for the digitisation of analogue television and, in its Program Stream version, the ideal solution for locally interactive television, thanks also to the very high performance of the audio and video coding algorithms. This has decreed the success of MPEG-2 to the extent that today MPEG-2 decoding chips are worth a few dollars and are available from multiple sources. MPEG has created a single common digital television industry that did not exist before!

Television, it must be remembered, is not just about Hertz and bits. Television is a business. MPEG was not just populated by engineers, incidentally, the best in the world. That is why MPEG-2 contains two features in support of those who want to use the standard as a tool for their business.

The first feature is the so-called Copyright Identifier. The audio and video components individually, as well as their combination at the systems layer, can be identified by a number assigned by an agency managing the rights of those streams. In its turn the agency is identified by a number assigned by an ISO-appointed Registration Authority.

The second feature is provided by the so-called Entitlement Control Messages (ECM) and Entitlement Management Messages (EMM). These provide an infrastructure that enables the sending of the audio-visual payload descrambling keys to remote decoders.

 

Fig. 1 – The role of ECM and EMM in MPEG-2 (example)

 

The payload is scrambled with a control word. This is sent scrambled with a service key via an ECM message. The control word is changed with a period of the order of 1 second. The service key is scrambled using a key drawn from the users’ data base and sent via an EMM message. As all users must receive the scrambled service key, this information reaches the intended user with a period of the order of 1 hour. At the receiver the scrambled service key is extracted from the EMM message, and is converted to clear text using the key stored in a smart card. In its turn this descrambles the control word which can eventually be used to descramble the audio-visual payload. This is where MPEG-2 Systems stops. Nothing is said about the nature of the keys, the scrambling algorithms etc.

3. The limits of MPEG-2 and its extensions

This was probably as much as an international body like ISO could specify in 1994, when MPEG-2 received its final touches. Therefore MPEG-2 has produced a standard technology where clear text transmission is universally interoperable, but encrypted transmission is SP-specific, unless a standard interface is defined that separates the source decoding and multiplexing from the content management and protection.

Several attempts have been made to make the system more open. A single STB may still be used to view different SPs if they team up to provide common access to their combined services. This is the so-called "Simulcrypt" (see Fig. 2).

 

 

Fig. 2 - Simulcrypt

 

In this case SP1 and SP2 send EMM messages (dotted lines) to the combined set of their subscribers, so that encrypted content (full lines) from both SP1 and SP2 can be viewed by subscribers of both. The shortcoming is that users can still view content that comes from somebody not selected by him/her but by somebody else for which they have no control.

Other attempts were made by industry consortia to decouple MPEG-2 decoding from access control. Two of these consortia are the European project Digital Video Broadcasting (DVB) and the international consortium called Digital Audio-Visual Council (DAVIC).

Fig. 3 - The DVB and DAVIC interfaces

 

Fig. 3 represents the two interfaces CA0 (defined by DVB and called Common Interface – CI) and CA1 (defined by DAVIC). CA0 is simply an interface where an external, SP-specific, box is plugged: high bitrate scrambled streams enter the box and leave the box in clear text. CA1 is a more elaborate interface where low bitrate signals such as ECM and EMM enter an external device (a smart card) and the control word enters the set top box.

Both solutions are still to see large scale deployment. This means that the STB is SP-specific and, if one wishes to view content from more than one SP, in general one needs more than one STB. Apparently, a contradiction was not perceived by European regulators when they mandated, in one of their directives, the use of MPEG-2 for source coding and multiplexing but remained silent about the access control part. Much as the author is flattered by the idea that the use of MPEG-2 is made legally binding in European digital television, he is riddled with doubts about its value. If the STB is proprietary, so could be source coding and multiplexing.

4. What users would like

The absence of standard STBs enabling access to multiple SPs is one of the causes why digital television services are having a slow take off. Fig. 5 illustrates what is the desire of the vast majority of people (next to view content for free).

Fig. 4 – An ideal digital television world

 

The user would like to be able to navigate through the different offers of multiple SPs, choose the one that is most interesting or convenient, pay and view. And that without even the need to stand up from the armchair in which he/she is sitting.

This is what the OPIMA has set out to make possible. OPIMA is based on the belief that the market would see a faster development if a standardised technology existed that would allow a user to acquire a device, and consume and pay for services, without having prior knowledge of which services would be consumed, in a simple way such as by operating a remote control device.

OPIMA seeks to support the basic services and service models such as

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 – the platform must allow free TV/Radio to be supported. (Note that this is a requirement on the whole platform; not on any specific implementation. A service provider may choose an implementation that blocks the consumer device completely – and hence also block access to free TV/Radio – for example if a user does not pay for a subscription service).

While a new technology is being developed it may be interesting to see whether other services cannot be supported, e.g.

1. Targeted advertising – The user obtains permissions/credits in return for viewing advertising content
2. 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)
3. 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
4. Information services – The content being obtained is not necessarily audio-visual, e.g., stock exchange information, traffic information, GPS information
5. Games (single or multi-user)
6. Software distribution – This is very similar to any other content distribution
7. 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
8. Auditing/Polling/Voting – This means that a service provider can gain knowledge about the number of users accessing services and their degree of appreciation
9. Other services.

5. Requirements

This section deals with the requirements OPIMA has developed for its platform. The word "shall" is used to indicate that a certain feature shall mandatorily be supported while "may" indicates that the feature may be supported if possible.

5.1 Generic nature of the platform

The platform shall be as open as possible. In particular, the platform:

1. Preferably does not require proprietary hardware;
2. Preferably does not require a specific operating system.
3. Shall support multiple content management and protection systems (these individual content management and protection systems may, of course, use proprietary technologies, including hardware and software, as long as the interfaces conform to the OPIMA specifications).

5.2 Security and Privacy

The platform needs to be secure and trustworthy. This means that:

1. The platform shall support identification and authentication of users and transactions (for example by digital contracts);
2. The platform shall prevent unauthorised access to information (i.e., access by parties that are not entitled to this information) and shall be robust against piracy. (Aspects of these requirements may be: preventing unauthorised copying of and access to content);
3. The platform shall support a means of assuring that users are only charged for services they have agreed to consume, and support giving the user an overview of the services consumed;
4. The platform shall support ‘non-repudiation’, i.e.
   • provide proof that the user has agreed to order/consume the service;
   • provide proof of payment;
5. The platform shall support provision of accurate accounting information;
6. The platform may support – perhaps by providing some of the functionality listed above – binding negotiations. (This requirement refers to a model in which, if a party bids for goods or services using the platform, and the bid is accepted by the other party, this bid is equivalent to a purchase agreement.)

If different levels of security and robustness against piracy are allowed, systems with lower security levels shall never be able to compromise systems with higher security levels.

The platform shall support access control by

1. parental control;
2. jurisdictional and cultural policy (i.e., legal restrictions, possibly geographically determined).

The platform shall support service models in which the user’s identity is not disclosed to the service provider and/or to other parties.

5.3 Connection type/form of interaction

This section lists requirements in the area of the type of connection and the form of interaction.

The following types of connection shall be supported:

1. Off-line consumption of content
2. On-line consumption of content, for which are distinguished:

a. Broadcast, with the following return channel characterisations:

1. without return channel
2. with intermittent return channel
3. with persistent return channel

b. Interactive, with the following return channel characterisations:

1. symmetric and asymmetric bandwidth
2. similar or different paths to and from the user

It is understood that these models and their sub-categories are not mutually exclusive.

Along a slightly different axis describing the connection, the platform shall be able to support:

1. One-to-one operation; such as sending content from a service provider to a user;
2. One-to-many operation; such as sending content to multiple users on a broadcast network;
3. Many-to-one operation; such as when a user receives content from several service providers simultaneously; the collection of information constitutes one consistent service.

Along the same axis, the following may also be supported:

1. Many-to-many, like in multi-party games, in which value is at stake.

The platform shall at least support:

1. service provider to customer operation.

In addition, it may also support:

1. customer-to-customer operation, in which value is transferred from one (end) user to another;
2. service provider to service provider operation.

5.4 Types of transactions

The platform shall allow a wide range of transaction models. At least the following types of transactions shall be supported:

1. prepaid;
2. postpaid;
3. subscription;
4. pay-per-use;
5. rent-to-own;
6. booking;
7. credit and debit;
8. end user pays; third party pays; service provider pays (possibly to the end user);
9. incremental purchase of permissions with respect to the same content, for example: one first obtains the permission to view, and afterwards the permission to modify or copy.

Both on-line and off-line connection modes are foreseen with these types of transactions. Please indicate which types of transactions are supported for each of the connection modes.

Again it is recognised that these transaction models are not mutually exclusive.

5.5 Device types

A device is a system that is used to access and consume information. In principle, the platform shall support any device that can be used to consume multimedia services. At least the following devices need to be supported:

1. Digital TV
2. Set top boxes
3. Local storage devices (e.g., DVD-RAM)
4. Digital Radio
5. Personal Computers
6. Mobile devices used to access multimedia services
7. Screen telephones
8. Others

5.6 Mobility

The platform shall support mobility. In particular, it shall:

1. support service models that allow terminal mobility, meaning that the user can use the same device in different locations;
2. have provisions for supporting user mobility across terminals, meaning that the users can move to a different terminal and keep their permissions to use the service.

It is to be noted that user mobility could be provided through ‘personalisation’ and the usage of ‘user profiles’.

5.7 List of Parties/Roles in the Value Network

The focus of OPIMA is currently on the relationship between the end user, and the service provider. It is recognised that many other roles exist in the value network. The platform shall not exclude the interests of these parties from being served.

These parties include:

1. Hardware manufacturers
2. Security providers
3. Service brokers
4. Rights holders

1. on content
2. on algorithms (e.g., coding algorithms)

1. Infrastructure providers
2. Transaction infrastructure providers
3. Legitimate third parties (Third parties such as trusted third parties, tax authorities, regulatory agencies, not including parties like pirates)
4. The end user in the role of service provider.

It is understood that several of these roles can be unified in one entity.

6. The OPIMA Reference Architecture

Fig. 6 is a representation of the system addressed by OPIMA specifications. It comprises four entities: the Service Provider System (SP), the Service Provider Support (SP') as seen from the end-terminal perspective, the trusted middleware (TMW); and the Smart Card (SC). In principle, OPIMA specifications can address any subsystem in a similar context.

Fig. 6 - The OPIMA Reference Model

 

Notes to the picture:

• The ‘H’ in OP_HX refers to OPIMA Hardware
• Trusted Middleware and Smart Card functions could also be carried together (e.g., on a PC card)
• Permissions are to be fully portable (e.g. on a Smart Card)
• Trusted Middleware is self-replaceable
• SP' is a generic service provider interface manufactured into every OPIMA device.

 

6.1 Elements of the reference model

Smart Card (SC)

The smart card is viewed as the user identification and service enabling module. The smart card may be provided to a consumer by a Service Provider or an independent vendor. It should not be limited to enabling access to a single service provider or to a single application. The smart card should be a secure environment whose integrity the consumer is confident of.

Service Provider System (SP) and Service Provider Support (SP')

The service provider is an entity which presents a unified image to a consumer who wishes to consume the services or products offered by the service provider. A service provider may have unique and proprietary applications requirements and interfaces. These are made transparent to the consumer by a secure download technology enabled by an OPIMA compliant terminal. This is accomplished by the presence of a generic (and secure) service provider support function (SP') in combination with a trusted middleware component (TMW) that is resident in each OPIMA compliant terminal at the time of manufacture.

Legitimate Third Party

A legitimate third party (LTP) is an entity whose presence in the system is authorised. This excludes unauthorised third parties such as pirates. The presence of an LTP is optional.

Trusted Middleware (TMW)

Trusted Middleware (TMW) is the core element in the system’s ability to provide secure and trusted services. Only a certified middleware component has the ability to incorporate and certify additional or replacement functionalities including replacing itself in a trusted manner.

The trusted middleware component is capable of communicating with the smart card and the service provider support functions. The trusted middleware component manufactured within each OPIMA terminal contains the necessary functions to facilitate the addition of the Service Provider elements of the TMW. This can be achieved via secure download or other trusted methodology. The basic TMW, without any additional elements, will allow the operation of the basic functions for which the terminal is intended. For example, a digital television without these additional elements can receive and display free TV services.

Functions that are specific to individual Service Providers may be added to the basic TMW. This allows one or more service providers to offer available services on an OPIMA terminal. Security and application protection and management are required when additional service enabling is provided.

The SP' and TMW functionality may be combined in a single entity. If they are not, an interface such as IEEE 1394 may be used.

6.2 The OPIMA approach to specifications

1. Relocation of tools. Because OPIMA specifications have to satisfy business and service models of multiple industries, OPIMA tools need not only to be usable in a variety of different systems but also in different parts of the same systems. OPIMA defines its tools in such a way that they can be relocated, whenever this relocation is technically possible and practically meaningful.
2. Specify the minimum. If the OPIMA reference model is mapped onto a particular application, the boundaries shown in the diagram may not be identifiable. As OPIMA addresses a multi-industry environment, it can only produce specifications of tools with the minimum of detail needed for interoperability.
3. Longevity. The technologies used by OPIMA systems are targets for attack by illegal operators and interests. Therefore, the technology and the nature of the tools that will be used by OPIMA conformant systems require flexibility and the ability to replace components as they are compromised or when better technology becomes available.

Copyright 1998, Leonardo Chiariglione, CSELT, All Rights Reserved