INTEROPERABLE PROTECTION
FOR DIGITAL MULTIMEDIA CONTENT

Bart J. van Rijnsoever, Peter Lenoir and Jean-Paul M.G. Linnartz
Dept. Processing and Architecture for Content Management, Philips Research
Prof. Holstlaan 4, WY 6, 5656 AA Eindhoven, The Netherlands

 

ABSTRACT

Interoperability between systems for secure delivery of content (audio and video) over the Internet or via digital television broadcasting is still hampered by the lack of interoperability among proprietary content protection systems. The OPIMA (Open Platform Initiative for Multimedia Access) specification offers a generic solution for multimedia terminals, in which the end-user’s terminal is adapted to a content protection system by downloading a corresponding plug-in. This paper describes the OPIMA solution and shows how it can be applied.

  1. INTRODUCTION

    2.

    With the current transition from analog to digital platforms for home entertainment, protection of audio and video against illegal copying is becoming a major issue. Technological advances in storage media (such as CD and DVD discs in particular the recordables or rewritables), networking (the ubiquitous Internet and digital television) and compression (in particular MP3 audio, and MPEG 4 video) not only offer tremendous opportunities for new business models, they also are a threat to the existing businesses of music and film distribution. This paper addresses several distribution mechanisms and discusses a flexible solution to protect content in these environments. Initially we will discuss digital television, a field where protection of content has a relatively long history. In this field the concept of OPIMA (Open Platform Initiative for Multimedia Access), which is the prime focus of this paper, has been developed. The ideas behind OPIMA also appear fruitful for protecting Internet or wireless network distribution. Further, in a discussion of the protection of content one can not omit an elaboration of the interaction with the business of prerecorded optical media (CD music and DVD video). Many digital television broadcasters sell their content under the control of a conditional access (CA) system [1][2][3]. These systems encrypt the MPEG-2 [4] signal before transmission and send decryption keys to the digital TV terminals (set-top boxes or integrated TV sets) of paying end-users. The terminals decrypt the signal and manage cryptographic keys and content access rights.

    Although standards exist for the embedding of control signals related to the CA systems in the commonly used MPEG-2 multiplex [1][6], the CA system messages themselves are of a proprietary format. This allows a CA system provider to have full control over his system so that he can ensure its security.

    Many digital TV terminals have been designed to work with a specific CA system. Such terminals limit the choice of the end-user to service providers who use that same CA system. In addition new service providers cannot easily use the installed base of terminals to deploy their services.

    This lack of interoperability between CA systems and multimedia terminals is a well-known problem, and a number of techniques has been developed that offer partial solutions. In SimulCrypt solutions [7], the same content item is independently protected by several CA systems. The terminal chooses the CA system it can cope with. If these systems use the same content encryption mechanism, it is sufficient to broadcast the encrypted content only once. Each CA system however continues to use its own control messages, so that these are transmitted for all CA systems in parallel. The disadvantage of SimulCrypt solutions is that they do not scale well to a large number of different CA systems.

    In MultiCrypt solutions, the end-user’s terminal is instantiated to work with a specific CA system. This is achieved by inserting a module that implements all functions that are specific for that CA system. In digital TV, the DVB (Digital Video Broadcasting) [5]‘Common Interface’ [8] and the OpenCable ‘Point of Deployment’ [11] are examples of this approach. These existing examples of MultiCrypt in digital TV have the disadvantage that they work with an expensive physical module, namely a PC card. Before an end-user can access a service, he or she first has to obtain such a physical module which is a serious impediment for the deployment of the service.

    This paper presents a MultiCrypt solution for interoperability between content protection systems and user terminals, based on the OPIMA specification [12]. The scope of OPIMA is multimedia in general, so it is much wider than digital TV alone. This solution uses a software plug-in (with the option to use a smart card in addition). Downloading of a software plug-in allows for much faster deployment.

    Such solution is also particularly suited for Personal Computers connected to the Internet. The download of software code is already common practice for Internet browser. The use of this mechanism for content protection functions, of course calls for specific security measures.

    Also mobile phones implementations increasingly tend towards a software radio concept, at least for the baseband processing part. The provision of entertainment content (MP3 music) on a handheld is already available in some products. An extension towards video is foreseen, and the issue of content protection is likely to arise soon.

    The authors have been actively participating in de creation of the OPIMA standard, and currently are part of the implementation and verification of the OPIMA standard in the European project OCCAMM [19]. This paper reports on their observations on the development of the vision behind the OPIMA concept and on their experiences with the implementation of the standard. The organization of the paper is as follows: Section 2 reviews content protection in various applications, in particular digital TV, DVD video and the Internet. Section 3 introduces OPIMA, and Section 4 shows how OPIMA can be used in the context of various applications.

    Section 5 describes the approach towards security and reviews remaining weaknesses in the system. Section 6 and 7 discusses implementation aspects. Section 8 concludes the paper by summarizing the achieved security and flexibility, in the light of the commonly accepted belief that security never will be watertight.

     

  2. CONTENT PROTECTION

    3. Broadly speaking two approaches exist for the protection of content: that of conditional access, which attempts to ensure that only legitimate subscriber can get access to the content, and copy protection, which attempts to ensure that the end-user can not make copies of the content even if he has acquired it in a legitimate manner. One distinction between the two approaches is that the former system can work with proprietary solutions, whereas the latter must rely on international standards. Nonetheless we see an important need to standaridize conditional access (CA) systems for interoperability reasons. Also, the distinction between these mechanisms is vanishing. The functionality of Copy protection (CP) systems is becoming more sophisticated, to the extent that access control is included in models for instance where the end-user is allowed to 'view n times".

    The next sections initially describe the state of the art in CA and CP as implemented in digital television and DVD video respectively. Then we describe how both concepts are interacting in digital music delivery over the Internet.

     

    1. CA for Digital TV

      2. CA systems enforce conditional content access by encryption, sometimes called 'scrambling.' Content decryption keys are provided only to authorized end-users. A CA system manages products, access rights and end-users. Products are sellable items like a subscription to a TV service or a pay-per-view program. A CA system may package products in many different ways that are deemed appealing for end-users. An access right is the right of an end-user to access (e.g., watch or record) a product. A CA system may define the access rights in a very detailed way by imposing restrictions. A CA system manages end-users like any commercial system manages its clients. In addition however, it is a characteristic of a CA system that end-users may try to illegitimately extend their access rights to others (e.g., by passing on content decryption keys). To prevent this, access rights are enforced by some tamper resistant environment inside (or connected to) the end-user’s terminal. A smart card is an example of such an environment.

      Conditional access systems for digital TV are proprietary systems. Many CA systems are however based on standards. Standardization of CA protocols facilitates interoperability between CA systems and end-user terminals through sharing of components. MPEG and regional standards bodies like DVB, ATSC (Advanced Television Systems Committee) [8]and OpenCable [9] have defined CA protocols. These protocols specify the encryption of content and the transfer of CA control messages in the MPEG-2 transport stream (TS), see Figure 2.1. The control messages themselves are proprietary for the CA system.

      Two types of CA control messages are distinguished. Entitlement Control Messages (ECMs) transfer content decryption keys to the tamper resistant environment in the end-user’s terminal. The content decryption key will be made available for decryption if a corresponding access right exists. An Entitlement Management Message (EMM) transfers a content access right to the tamper resistant environment of a specific end-user. In addition, EMMs are used for key management.

       

      Figure .1: MPEG-2 CA system.

       

    2. CP for audio and video on storage media

      3.

      The development of DVD video has launched an unprecedented debate on copy protection. Content in the digital domain is protected by cryptography. This leads a compliant world of consumer devices which communicate over authenticated and encrypted digital links. A device is compliant when its manufacturer has agreed to follow specific copy protection rules described in a licensing agreement, in return for knowledge of cryptographic keys to get access to protected digital content. Hence, non-compliant devices never get access to the digital content in the clear. Consequently protected digital content must be (re-) encrypted on any "open interface." This includes digital interconnects, over the air broadcast, PC-card connectors, internal PC busses, etc. The licensing agreement prohibits the use of ‘insecure’ interfaces.

      Encryption of content as such is not sufficient. An attacker can copy encrypted data, which compliant devices inherently would understand during playback. To prevent such a replay attack, an authentication mechanism and session key generation is needed for all interfaces. Furthermore, the digital representation on a storage medium, such as a recordable CD or DVD disc needs protection against bit-by-bit copying of encrypted data. One way of dealing with this is through unique media and disc identifiers, which can not be changed by hackers.

      While the above measure can protect content in the digital domain, content eventually needs to be presented in the clear to the human consumer. Digital protection can be extended all the way to digital monitors and speakers, but eventually an analog signal, vulnerable to (non-compliant) copying must be created. Additional protection is needed to prevent that this analog signal can successfully be offered to a (compliant) recorder, as if it were the end-user’s personal creation. To prevent copying through an analog circumvention route, some (water-) mark is added as an indelible part of the content. Modern advances in the modeling of the Human Visual/Auditory System have opened the possibility to embed these marks imperceptibly in the content, usually by making minor modifications to the signal values. Such embedded signaling resemble electronic "tattoos" as these ensure that marks are not lost in typical operations on the content, including format conversions [*] .

      Watermark detectors can be incorporated in compliant recorders. Copyrighted ‘never-copy’ content will then be recognised as such, and the ‘record control’ functionality of the recorder refuses to store material for which the end-user has no rights to copy it. For at least two reasons this approach is insufficient. Firstly, for a hacker or small-scale pirate it would be a relatively simple task to modify his own recorder or video grabber software and to create content that plays on the devices used by his customers. Secondly, the DVD licensing mechanism for compliance has been build upon playback devices, thus not around recorders. Both aspects can be resolved by ‘play control’. The basic concept of ‘play control’ is that the player or render device (also) recognizes the copy state of the content by detecting the watermark, and compares this with a cryptographic identifier that travels with media. If this mark is correct and matches with the watermark, the device is authorized to render the content.

       

    3. Internet Delivery: Combining CA and CP

      4.

From a content owner perspective, the second aspect is most to his concern.

Several proprietary Digital Rights Management (DRM) systems have been developed for the Internet. DRM systems are usually more advanced than the CA systems used in digital TV, however basically they serve the same purpose. DRM systems typically protect not only the transmission of content between server and client, but they also protect local content storage and forwarding of content between end-users (often called superdistribution). In other words, DRM systems offer persistent or end-to-end content protection. Further DRM systems typically implement an advanced rights model, where access rights and rules are described in a detailed way. As an example a DRM system may not only either allow access or not, it may also control what type of access (e.g., render on monitor, print, copy) is allowed. Some DRM systems also ensure the security of content purchase transactions, other system consider this separate functionality.

The Secure Digital Music Initiative (SDMI) is a standardization effort that has defined requirements for (music) players that ensure copy protection. Such players may implement a proprietary DRM system, because its specification is outside the scope of SDMI. SDMI has focussed on the import of music into the secure SDMI environment. A proposed solution is to screen content that is offered to a end-user terminal (either arriving over the Internet of from a local source). An example of such a screen is a watermark detector that searches for embedded copyright information in the audio signal.

It is an end-user expectation, now accepted by the music industry, that a customer must be able to take content from a CD that he bought in the store and enter it in his digital jukebox or solid state walkman. However, the end-user is not supposed to make that content available to others as an MP3 file via the Internet. A solution proposed in SDMI is to use two watermarks, a robust one that survives digital signal processing such as MP3 compression and a fragile one, which is lost during MP3 compression. In such a scenario, an SDMI device will accept legacy content that contains no watermark. Also it will accepts new content with the robust and a matching fragile watermark. However, content containing only a robust watermarkwill be rejected, because this content has presumably been illegally distributed on the Internet.

 

  1. OPIMA

    2. OPIMA (Open Platform Initiative for Multimedia Access) is a specification that enables interoperability between content protection systems and multimedia terminals. The scope of OPIMA is very wide. Various parties from the consumer electronics industry, the IT industry, and academia have contributed to OPIMA. OPIMA is not restricted to digital TV and includes for example delivery of music through the Internet.

    The goal of OPIMA is to create an open market for content delivery. In digital TV and other application areas, content protection systems tend to prevent the development of a horizontal market in which the end-user can use his or her multimedia terminal to access the content offerings of all service providers. Traditionally a terminal supports only one content protection system which severely limits the number of services that can be accessed.

    The solution provided by OPIMA is a MultiCrypt solution, see Figure 3.1. In a MultiCrypt solution, a generic multimedia terminal is instantiated for a specific Intellectual Property Management and Protection (IPMP) system by downloading a corresponding software module or by inserting a corresponding hardware module. The module implements all functions that differ between different IPMP systems.

    Figure .1: MultiCrypt

    OPIMA defines the OPIMA peer model of a multimedia terminal, see Figure 3.2. The OPIMA Virtual Machine (OVM) guarantees the security of the IPMP plug-ins. These plug-ins embody content access rights and the identity of the end-user, so they must be protected from attacks by for example the end-user. How the OVM implements this protection is not defined by OPIMA; it is left as a task for an application domain that adopts OPIMA.

    The OVM implements two application programming interfaces (APIs). The Application Services API enables the use of OPIMA by independent applications. Using this API, an application like for example a software player may request access to a specific content item identified by a URL.

    The IPMP Services API enables MultiCrypt. It allows downloaded IPMP plug-ins (or, modules) to access the functionality of the multimedia terminal. The IPMP plug-in implements all functionality that is specific for a specific IPMP system in an application domain. Functions that are common in an application domain (like transmission and storage formats and possibly also content decryption) are implemented by the OVM.

    The IPMP Services API also allows for communication with a smart card at the command level [13]. This means that the IPMP module in Figure 3.1 may be a combination of software plug-in and a smart card.

     

    Figure .2: OPIMA peer model

    OPIMA defines Secure Socket Layer (SSL) as the secure plug-in download protocol [14]. The SSL protocol is a secure authenticated channel between plug-in server and OPIMA peer. The protocol ensures the secrecy and the integrity of plug-in code during downloading. Also it allows mutual authentication of server and OPIMA peer. The server will verify that the OPIMA peer is a trusted peer and vice versa. This requires that the plug-in server and the OPIMA peer use certificates authenticated by a common certification authority.

     

  2. COMPARTMENTS OF OPIMA

    3. The OPIMA specification is independent of a particular application. However, a 'one size fits all' approach cannot be adopted across a wide range of devices with different processing capabilities. This means that before OPIMA can actually be used the specification will have to be tailored to a specific environment. An example of this is the choice of a content encryption algorithm. Such a further detailing of the specification is one of the elements that defines an OPIMA compartment. The second compartment defining element is some degree of trust between the suppliers of OVMs and of IPMP systems. In order to achieve interoperability across IPMP systems, it is required that these systems can share an OVM. Such sharing presupposes trust.

    This section describes three examples of compartments, focussing on the functional consistency in a compartment.

     

    1. DIGITAL TV

      2.

      A digital TV terminal may implement an OPIMA Virtual Machine, and CA system specific processing of control messages may be implemented as an IPMP plug-in. The IPMP Services API offers the plug-in access to all terminal functions it needs. The API is abstract in the sense that it is independent of the type of content or the type of multiplex that is protected by the CA system. All content or multiplex specific functions are implemented by the terminal, so there is a decoupling of content protection control on the one hand and content processing, multiplexing and transmission on the other hand.

      The IPMP Services API also offers access to a standard smart card. Many CA systems use a smart card. The smart card serves as a store for access rights and cryptographic keys. Further it implements all processing of ECMs (Entitlement Control Message) and EMMs (Entitlement Management Message). In that case one of the tasks of the IPMP plug-in is formatting of smart card commands and interpreting of results.

      The subsections below describe how the OPIMA model supports the main CA process: content decryption and updating of access rights.

      1. Content decryption

The process of content decryption is initiated by the end-user who selects a service protected by a CA system. Tables in the MPEG-2 Transport Stream indicate which CA system is used for the protection. If this CA system is not available in the terminal, a plug-in download procedure may be initiated, see Section 3. After the corresponding plug-in and, if applicable, a corresponding smart card have been obtained, the following procedure is executed between plug-in and OVM:

  1. Using the abstractAccessToContent method of the IPMP Services API, the OVM indicates to the plug-in to which content item access is requested. The OVM also indicates the nature of the access (e.g., rendering or copying) and the destination of the content. The content item is identified to the plug-in by a generic identification. This identification is used to refer to the content item in all communication between plug-in and OVM.

  2. Using the obtainContentRules method, the plug-in subscribes to the ECM stream associated with the requested content item. The plug-in uses the content identification that was earlier provided by the OVM. Content encryption keys, and thus ECMs, may change frequently. This is why a subscription model is used. The OVM will filter the MPEG-2 TS in order to retrieve the ECMs.

  3. Upon arrival of an ECM, the OVM will pass it to the plug-in using a call back function. The plug-in will process the ECM to obtain the content decryption key. This processing involves ECM decryption and authentication, and verification that an access right for the requested content exists. If not, it may be possible to acquire the access right, see Section 4.1.2. A dialog with the end-user may be required to confirm that an existing access right may be used (e.g., a password dialog to ensure parental guidance). The sendMessageToUser method can be used for this purpose. The IPMP Services API offer functions similar to a cryptographic API. If a CA system uses a smart card, the smart card will do most ECM processing. The plug-in will embed the ECM in a smart card command and interpret the smart card response. The plug-in may use the sendAPDU method to submit commands to the smart card, after the smart card communication has been set up.

  4. After an ECM has been processed successfully, the content decryption key is known to the plug-in. The OVM implements a content decryption engine. After the decryption engine has been set up, the plug-in will submit the key to this engine using the updateDecryptionKeys method. This method also allows for synchronization of key changes.

      1. Updating access rights

        2.

Before an end-user is allowed access to content, a corresponding access right shall be established. In a broadcast scenario the access rights are stored locally in the terminals, so that no contact between clients and service providers is required for clients that access services for which they are already entitled. In smart card based systems, access rights are stored in the smart card.

The IPMP plug-in may use a point-to-point communication channel to contact the service provider. In addition it may communicate with the end-user through corresponding API calls. The IPMP plug-in may use these facilities to request new access rights from the service provider.

Alternatively, it is possible that the end-user contacts the service provider using means not defined by OPIMA. In that case, the service provider sends an EMM confirming the access right to the OPIMA peer either using the MPEG transport stream or using a point-to-point connection. The IPMP plug-in may ask the OVM to filter specific EMMs out of the MPEG stream, using the obtainUserRules method in the IPMP services API. In calling obtainUserRules, the plug-in passes to the OVM the user identification needed for filtering. Again, the OVM implements all functions specific for an MPEG-2 transport stream. Alternatively, the IPMP plug-in may wait for the service provider to open a point-to-point connection by calling the addConnectionListener method.

 

    1. The Internet

      2.

An important feature of the Internet is the point-to-point connection structure. This means that every end-user terminal (like a PC or a specialized set-top box) has in principle a dedicated communication channel to the content provider. So a content provider can send the necessary user rules, needed for access to the content, to every end-user personally. This situation is different from the digital TV world, where both content rules and user rules are part of the broadcast content distribution.

Another difference is the access characteristic of the end-users. In the digital TV world, end-users generally have a subscription to a set of services and thus the access rights for these services can be transferred to the end-user's terminal sometime before the actual content access is performed. In the Internet world, the typical access pattern is instant access to the content server when a specific content item is found.

The actual sequence of events in the terminal is mainly the same as when TV channel is accessed, but has some specific aspects. As example we will explain the events for an on-line music trial that is currently implemented as part of the OCCAMM project which we will describe in section 0.

  1. The end-user searches for content on the Internet on sites that have access to their content enabled via OPIMA technology. When the end-user finds something he likes, he can download or stream the content to the OPIMA-enabled player on his terminal.

  2. When the end-user plays the content, the player will request the OVM (OPIMA Virtual Machine) via the Application Services API to access the content for a specific purpose (rendering, copying, etc.) and to install the necessary IPMP system. If the IPMP system is not yet available it will be downloaded from a server that is indicated in the content stream.

  3. When the IPMP system is installed, the OVM will request the processing of the necessary content rules (which are embedded in the content stream) and user rules. In the on-line situation the user rules can be transported separate from the content, by for instance a separate session between the IPMP system and a special purpose server on the Internet. This scenario contrasts a digital TV system, where the user rules (EMMs) are embedded in the content (the MPEG-2 transport stream). When the processing of both the content rules as well as the user rules is finished, the IPMP system can decide whether or not the end-user is allowed to have access to the content and the OVM will endorse this decision.

      1. OPIMA and Internet music delivery

SDMI (see section 2.3) is an important movement with the aim of protecting the music content on the internet. It is thus important to see how OPIMA can be used inline with the rules of SDMI. The rules of SDMI indicate how content should be handled when it is stored or transferred and it indicates how devices/terminals should be implemented.

SDMI is defining their own domain in the sense that when content is protected, it is assumed to be legal content. Content is protected when it is encrypted and the access to the decryption keys is controlled. This content is just handled and the end-user can only have access to the content according to the rules of that accompany the content. The mapping of this part of the SDMI protection onto the OPIMA architecture is relatively straight-forward.

A major concern of SDMI is the import of illegal content. Importing content is the storage and access of unprotected music in a regular SDMI compliant terminal. When content is imported, the terminal has the duty to check the content for signs of IPR restriction and to prevent further manipulation of the illegal, unprotected content. In general the IPR-restriction-checks are checks for the presence of certain standardized watermarks. This part of the SDMI protection is a bit more difficult to map onto the OPIMA architecture, as the activation of the watermark checks is performed by an IPMP system. To require that every content item is checked for the presence of the SDMI watermarks implies that the IPMP module controlling these checks is permanent available and installed in the terminal.

 

    1. Mobile Phones

Low bandwidth is currently the main constraint for mobile phones. Furthermore is also the low power requirement a major technological hurdle. To meet these constraints it is essential that both the OVM as well as the downloadable IPMP system are low weight, i.e. a small binary, This means that the downloading of the IPMP system is relatively fast, and that the execution of the code is not extremely power hungry. Therefor the mobile phone environment classifies as a separate compartment of OPIMA. Currently this is still not developed in great detail.

 

  1. Security aspects of the OPIMA system

In the previous sections we described mainly the functional aspects to the OPIMA architecture, which enable the downloading and execution of different IPMP systems, and the access of a wide range of content types and services. However the architecture is mainly developed to join the security requirements of content providers with interoperability across service providers.

Looking at the architecture of OPIMA there are several points where a hacker could try to gain illegal access to the content. We will list the possible attacks and explain how the OPIMA architecture and the basic assumptions will counter those threads.

However, given this list of threats and countermeasures, one has to realize that these countermeasures do not prevent hackers/adversaries to break the security of the system. There are several reasons why a system can still be broken and one of the main reasons is the use of flawed implementations. Some of these are high-profile hacks and can have a devastating result on the system such as the hack of the DVD encryption and key management scheme, in which the hacker could exploit a flaw in the security of the implementation. Others are not as known as the DVD hack, like a hack of an The Secure Socket Layer (SSL) implementation (SSL secures the communications between two computers on the Internet), which was due to a flawed implementation of the random number generator.

As security systems can (and will) be hacked, it is therefore prudent to always keep in mind that this can happen and to make sure there are recovery mechanisms to keep the hacks as limited as possible. In for instance the case of the DVD hack some system secrets became public knowledge and because these secrets were very basic for the system no recovery was possible. In case of the SSL hack, only a single program was affected and the security of the system was maintained as more secure implementations could replace the flawed one.

The security of the OPIMA architecture is based on several assumptions, concerning the implementation of the terminal. First and for all, OPIMA assumes that the OVM is a secure implementation and that the OVM provides a secure execution environment for the downloadable IPMP systems. Furthermore all the content manipulation is performed inside the OVM. The reason for these assumptions are the following attacks on the system:

In the OVM several critical security functions are combined, which make the OVM an interesting object for hackers to try to obtain access to the clear content or to the communications with the IPMP system.

A major obstacle for the hackers is the complexity of the OVM. The OVM is actually more like an operating system controlling the access to physical resources (memory, processes, communication channels, etc.), controlling the time resources (scheduling of processes) and controlling the inter-process communications of the applications and running IPMP systems.

The downloadable software of the IPMP system controls the actions of the OVM on the content. It is therefore an attractive target for hackers to try to alter it in such a way that the control of the content effectively is canceled. The software could be altered when the software is downloaded, when it is temporarily stored on harddisk, or when it is running in memory. The architecture of the whole system should prevent this from happening.

The communication between the OVM and the IPMP systems goes via the IPMP services API. This inter-process communication is target for hackers as for instance the keys for the decryption of the content are transferred via specific calls of this API. The implementation of the OVM should prevent this.

Analog content is always available for hackers as the output of the OVM, because the human sensors do not like digital information. It might therefore be interesting for hackers to try to illegally import the analog content again into the OVM, with the aim to get it accepted as legal content

Above the major attacks on an OPIMA system are listed. In the definition of the architecture and the standardized API’s and communication channels these attacks are dealt with.

The major requirement on the OVM is that it provides a secure and trusted environment for the execution of the IPMP systems and the manipulations of the content. The ultimate solution of this goal is probably the implementation of the OVM completely in hardware. However this is for most cases an overkill and one could probably also be sufficiently happy with an integration with the OS or as a special program to be executed only by the OS.

Specific measures should than still be taken to prevent the execution of altered code. This could be performed with digital signatures if the OS is made to check for these signatures. Making the OVM self-checking could also be a possibility, however the technology for this is still not come to age.

This attacks are prevented using a set of precautions. First the downloading of the IPMP system is performed through a SAC (Secure Authenticated Channel). This includes the identification of the other side of the communication whether or not it belongs to the trusted set of applications and includes the encryption all communications, which prevent eavesdropping or altering of the communications.

When the IPMP system is downloaded, it will be stored in a secure (encrypted) place (harddisk or flash memory). To circumvent these precautions, one should change the OVM code to either influence the download on the sending side or to access the secure storage.

This is currently not ruled in the OPIMA standard. As it is obvious that the API is a prominent place to attack the system, the implementers of the system should take care of this. However, due to the nature of the API communications and the way these are implemented on different systems, this problem is very much device/implementation dependent.

An OPIMA enable system should be able to detect those watermarks and to act accordingly.

  1. OPIMA Standardization

    2.

    Verification of the standard

    The specification process of the OPIMA standard 1.1 [12] started by several influentual and original contribution in response to the call for proposals. The specification was generated during a series of 10 meetings. It was released in July 2000 after a period in which comments on the standard 1.0 could be committed. Until recently no implementations of the standard have been reported. However a verification of the consistency and correctness of the standard is still underway in the EC funded project "OCCAMM". OCCAMM stands for "Open Components for Controlled Access to Multimedia Material". More detailed information can be found at the OCCAMM website [19].

    The prime goal of the project is to develop a working implementation of a content delivery system based on OPIMA. The OPIMA standard is a framework where several elements still have to be defined to come to a working system. For each different application area (compartment) the choices for these elements can be different. Within the OCCAMM project a set of choices have been made with regard to the content encryption scheme (AES, Advanced Encryption Standard), the content decoder (MPEG-4) and the watermarking algorithm (CRL). Furthermore it was chosen to use Microsoft software technology on standard PC's as implementation environment. These choices, together with the supporting content delivery environment, define the OCCAMM compartment. During the project an implementation has been developed of the both the delivery environment and end-user terminal, this is the OVM, the application and three downloadable IPMP plug-ins for three different content protection systems. The partners developed the OVM in very close cooperation. The application and the three IPMP systems were each developed by a single partner.

    Preliminary result from this work has been the clarification of the sequence of calls across the OPIMA APIs. From the OPIMA standard this sequence is not completely clear.

    The APIs were found to be behaving correctly except for some small changes in the parameters of some API-functions. These will be detailed in the final reports of the project and all these results will be submitted to OPIMA for consideration in the next version of the specification.

    To be able to test and use the implementation in trials also a supporting delivery and E-commerce system had to be defined to give the end-users of the trials an experience as real as possible. A typical set-up of such a configuration is shown in Figure 6.1.

    Figure .1: A typical trial configuration in the OCCAMM project

    The implementation will be used in four different trials and demonstrations to develop an understanding of commercial feasibility and user acceptance of the system. A major aspect of these trials is to show the interoperability of the content protection systems. The first trial will be the on-line distribution and controlled consumption of music. In this trial the content is constantly under protection of the IPMP system.

    In two trials (the exchange of pictures and a voice-dubbing service) the emphasis is on the protection of the pre-view of content. After the pre-view has been accepted and the end-user decides to buy the content the end-user will get free access to it.

    In a fourth trial (tele-education) the emphasis will be on the protection of educational material in a university environment.

    Final conclusions on the implementation and the results of the trials will be publicly available after the end of the project in March 2002. Preliminairy results of the user experience in these trials is unfortunately not yet available.

    1. MPEG-4

      2.

      MPEG-4 has extensively discussed copyright protection issues but thus far did not intend to define a common solution. The main motivation has been the vulnerability of a standardized solution to security breaches and the lack of flexibility to accommodate new services, features, and business models. The main objective for MPEG-4 has been the requirement of interoperability, both from the point-of-view of end-users (an end-user can access MPEG-4 content from different content- and service providers with the same terminal) as well as from the point-of-view of the industry (security providers do not need to develop 10 different implementations of their system for 10 different types of terminals). OPIMA addresses mainly the interoperability of the end-user terminal.

      OPIMA has been proposed in MPEG-4 as a flexible solution, which allows the upgrading of key-components in the security architecture. It also allows interoperability of service providers as they can download their own proprietary part of the system.

       

    2. TVanytime

      3.

    TVanytime is an industry consortium that aims at merging the concept of television broadcasting with of local storage. A Personal Video Recorder (PVR) is an intelligent set top box with a large hard disk. The hard disk stores broadcast content in a digital format. Many advanced applications (like filters and Electronic Program Guides) support the end-user in the usage of the PVR. The standardization within TV anytime attempts to generalize this idea.

    Besides the functional requirements on such personalized storage system, there are also requirements on the protection of stored content. The content owners (e.g. movie studio's) do not want their content to be freely available to hackers. Also service providers (e.g. Canal+) like to keep control over the stored content as they see the possibility for storage as extra service, for which the consumer should be paying. The solution currently being pursued by TVAnytime is a version OPIMA, where some fixed base IPMP systems are already installed.

     

  2. VLSI Implementation Aspects

The feasibility of implementation of conditional access on typical hardware platform has been a key issue throughout the entire creation process of the OPIMA concept. High performance DSP tasks, such as decryption and watermark detection are executed in the OVM. This implies that these tasks can be implemented efficiently. While the choice of the OVM algorithms has not been made within the OPIMA framework, evidently each compartment must select its set of algorithms. Meanwhile the watermarking solution must be the same among multiple compartments, because content can leak from one compartment into another.

As an indication of the computational burden of the processing, we can summarize the following:

Encryption: for assymetric algorithms implementations of modular arithmatic units in smart cards are a good indication of the hardware complexity that is needed for efficient execution. See [17] for a reference article on smart card IC's.

An important, but not well understood aspect is that of the security of the platform. It is obvious that all the techniques for securing the content during transmission or storage is to no avail if the the terminal, where the content is consumed is insufficiently protected. Most current secure implementation of information processing rely on the physical security of IC's or tamper resistant pakaging. Examples here are the security measures for smart cards. Due to the physical nature of these measures they allow for less flexibility than using software.

Therefore the idea of secure and tamperproof software gaining popularity in recent years. However, the techniques currently available are not yet up to the standards available with pure hardware implementations. Furthermore, for these techniques a lot of additional processing power is needed.

 

  1. CONCLUSIONS

    2.

    The OPIMA solution for interoperability between content protection systems and multimedia terminals is applicable in the application domain of digital TV. If applied, it will ensure a horizontal market for set-top boxes, integrated digital TVs, and other multimedia terminals that provide access to digital TV services protected by conditional access. This is of great benefit to consumers and facilitates the entrance into the market for new service providers.

    OPIMA is a framework. Its application requires further specification, especially of the IPMP Services API. An example is the choice of a specific content encryption algorithm. Further specification is a task for application domains that choose to adopt OPIMA. The application domain has to identify the common elements (standards) followed by the content protection systems in that domain. DVB for example specifies how to embed ECMs and EMMs in the MPEG-2 transport stream. It also specifies a content encryption algorithm (‘Common Scrambling Algorithm’). Note however that the management of access rights and clients is and remains proprietary for the content protection system. Smart card based systems can continue to use their existing smart cards. The aspect of renewability is seen as a step forward in the ongoing cycles of security solutions being broken and upgraded.

    An application domain using OPIMA has to introduce a certification authority in order to facilitate secure downloading of IPMP plug-ins into trusted multimedia terminals.

     

  2. List of acronyms

    3.

    AES: Advanced Encryption Standard

    API: Application Programming Interface

    ATSC: Advanced Television Systems Committee

    CA: Conditional Access

    CP Copy Protection

    CPTWG : Copy Protection Technical Working Group

    DRM: Digital Rights Management

    DVB: Digital Video Broadcasting

    ECM: Entitlement Control Message

    EMM: Entitlement Management Message

    IPMP: Intellectual Property Management & Protection

    MPEG: Motion Picture Expert Group

    OCCAMM: Open Components for Controlled Access to Multimedia Material

    OPIMA: Open Platform Initiative for Multimedia Access

    OVM: OPIMA Virtual Machine

    SAC: Secure Authenticated Channel

    SDMI: Secure Digital Music Initiative

     

  3. REFERENCES

    4.

  1. "Functional model of a conditional access system", EBU Technical Review, pp. 64-77, Winter 1995.

  2. Guillou, L.C. and J.-L. Giachetti, "Encipherment and conditional access", SMPTE Journal, pp. 398-406, June 1994.

  3. Macq, B.M. and J.-J. Quisquater, "Cryptology for digital TV broadcasting", Proceedings of the IEEE, vol. 83, no. 6, pp. 944-957, June 1995.

  4. "Generic Coding of Moving Pictures and Associated Audio: Systems", ISO/IEC 13818-1, 1996

  5. DVB: "Digital Video Broadcasting": http://www.dvb.org/

  6. "DVB; Support for use of scrambling and Conditional Access (CA) within digital broadcasting systems", European Telecommunications Standards Institute ETR 289, 1996.

  7. "DVB SimulCrypt; Part 1: Head-end architecture and synchronization", European Telecommunications Standards Institute TS 101 197-1.

  8. ATSC: "Advanced Television Systems Committee": http://www.atsc.org/

  9. OpenCable: http://www.opencable.com/

  10. "Common Interface Specification for Conditional Access and other Digital Video Broadcasting Decoder Applications", CENELEC EN 50221, 1996.

  11. "Point of Deployment Module Interface Specification", Society of Cable Telecommunications Engineers, DVS 131.

  12. Open Platform Initiative for Multimedia Access, "OPIMA Specification", version 1.0, IEC/ITA, 1999, downloadable form http://www.iec.ch/opima/

  13. "Identification cards – Integrated circuit(s) cards with contacts", ISO 7816, 1987.

  14. "The TLS Protocol Version 1.0", IETF RFC 2246, downloadable from http://www.ietf.org/

  15. "Hardware Performance Simluations of Round 2 Advanced Encryption Standard Algorithms", B. Weeks, M. Bean, T. Rozylowicz, C. Ficke; NSA (preliminairy version presented at the AES3 conference), downloadable from http://csrc.nist.gov/encryption/aes/round2/r2anlsys.htm

  16. M. Maes, T. Kalker, J.P.M.G. Linnartz, J. Talstra, G. Depovere, J. Haitsma "Digital watermarking for DVD-video Copy-Protection, What issues play a role in designing an effictive system?", IEEE Signal Processing Magazine, September 2000, Vol. 17, No. 5, pp. 47-57.

  17. D. Naccache, D. M`Raihi, "Cryptographic smart cards", IEEE-Micro (USA), vol.16, no.3, p.14, 16-24, June 1996.

  18. M. Balestri, S. Dal Lago, J. Guimarães, P. Kudumakis, P. Lenoir, S. Voukelatos; "OPIMA: A secure and interoperable framework for IPMP solutions", International Conference on Media Futures, 8-9 May 2001, Florence.

  19. OCCAMM: "Open Components for controlled Access to Multimedia material": http://sharon.cselt.it/projects/occamm/