The new mobile handsets with all the fancy features are naturally increasing the demand for high quality mobile content. For consumers, this means it can't just look good, it has to be easily accessible and relevant too. The price for all this? Higher authoring costs, higher delivery costs, and increased costs for rights acquisition; all with the hope of increased revenue. The concern for those investing in content creation are abundantly clear: How to keep consumer content usage in line with the intellectual property rights of the interested parties, copyright holders, content authors, and distributors? At the same time, the protection afforded to rights holders must be applied non-intrusively. After all, if the consumer has to type in a password each time they play a game, they might go elsewhere.
One technical approach to this issue is Digital Rights Management, or DRM, which strictly controls the use of the content on the target platform. Most DRM solutions involve some kind of cryptography, a protocol for delivering and managing keys, and software capable of encryption and decryption of content files. However, for any DRM solution to be successful, all the members of the value chain must buy into the process, including those producing the content, those delivering the content and keys, those producing the devices, and, ultimately, the consumers. The whole process becomes impractical if all of these groups have to use various technologies and tools. Therefore, the key to this whole process is to have it governed by a set of open standards. If these standards are open and accessible, they are much more likely to address the concerns of the involved parties and have a better chance of being applied.
This is where the Open Mobile Alliance (OMA) can be helpful.
The mission of the OMA, founded in 2002 by a consortium of some 200 vendors and service providers, is to define standards that benefit everyone involved in the creation, provision, and delivery of mobile data-centric services. Already, the OMA has published material on a variety of subjects, including Location Based Services, Messaging, Mobile Commerce, Security, and Push to Talk communications. One key difference between the OMA and other standards groups is that instead of dividing problems and standardizing solutions by technology, it assembles cross-functional groups; this leads to a process that is in tune with the business requirements to which the technology is applied. The OMA DRM is an example of this.
The current standard is at version 1.0, though version 2.0 has recently passed the first part of the certification process. Version 2.0 proposes to add, among other things, device certification and content integrity. It is also supposed to be entirely backward compatible. Although this article focuses primarily on version 1.0, it does briefly discuss version 2.0. The OMA DRM standard was designed to allow the technology to support the business requirements of content providers.
DRM version 1.0 specifies three main methods for delivering DRM-encrypted content and any applicable associated rights.
The content file's two components are the DRM-enabled content file and the rights object. The rights object is the encryption key as well as the associated instructions on how the content can be used. These rules are expressed in the rights expression language.
- Forward-Lock stipulates that after a DRM-wrapped piece of content has been received, it cannot be forwarded from the device. This is achieved by defining a flag rather than actually encrypting the file. The DRM agent, the phone for instance, must then not allow the user the option to forward the file. The specification also stipulates that if the content is placed onto removable media, the move is a move and not a copy. There must still be only one instance of the file.
- Combined delivery is when the DRM-encrypted file is delivered to the handset along with a rights object. In this instance, the right is typically a preview or some other limited execution or view right. The content can potentially be forwarded from the device, but the rights object is specific to the device. It is the DRM agent's responsibility to ensure that the rights object is not forwarded.
- Separate Delivery is when the encrypted DRM file is downloaded to the handset and the rights object is delivered through some other secure channel. Typically, this happens using WAP Push, a special form of Short Message Service (SMS) with binary content embedded within it. This is currently the best way to ensure that the rights object is not intercepted and that it is delivered to the intended recipient.
In this specification, the concept of separate delivery has been deliberately designed to allow for superdistribution, which means that the content can be forwarded from handset to handset or broadcast, and content user agents on devices can locate rights. This is done by delivering a URL with the content, which allows rights to be selectively delivered. For example, a piece of time-limited content might have rights freely available for it from a source, typically a wap site. However, after a given time (for example, after the closing date for a competition), rights can be made unavailable.
The Rights Expression Language (REL) is an XML language used to inform the DRM agent on how a piece of content can be used. The REL has a number of different goals; generally, the language is supposed to be an applicable abstract to the content type or device type. It has also been optimized for delivery over low-bandwidth transport routes to devices with limited computing resources. It does not consist of dozens of different elements in nested structures of complex XML. These rights, linked in semantic groups, are:
- Foundation model
- Agreement model
- Context model
- Permission model
- Constraint model
- Security model
The foundation model defines the fundamental group of rights and is the basis for all of the models.
The agreement model follows this, and represents the permissions granted for the content use. Inside the agreement model is a reference to the content, or asset.
The context model adds metadata about a particular set of permissions contained in the permission model.
The permission model contains the actions performed with REL V1.0 content. These actions are Play, Display, Execute, and Print. The constraint model determines the frequency and applicability of the permissions by defining a mixture of time periods, intervals, and counters. The file could be set, for example, to only be played (the permission) three times on a Friday (the constraint).
Finally, the security model defines the encryption keys to be used, if applicable, for a given piece of content.
The technology as it stands now is designed only to keep the honest people honest. At the center of OMA DRM V1.0 is a correctly functioning DRM agent. In fact, this is an issue at the center of all DRM systems; ultimately, the DRM agent or player or handset has to decrypt the file and render it in a useful format. Unless the decrypted file is tightly coupled with a system processor that is doing the rendering, there is space for the decrypted content to be redirected.
The DRM agent is also responsible for ensuring the key does not leave the device and that a key from another device cannot be used instead. Unless hardware is involved, which makes the retrieval of the device-specific key considerably more difficult, the potential for the protocol to be appropriated is great. Although hardware does exist to combat these potential problems, someone could conceivably get the key, read the specification, and write a misbehaving DRM agent.
Ultimately, security in systems such as these is a trade-off between usability, cost and availability. You could encrypt the file based on someone's fingerprint, but it wouldn't be particularly useful, and the cost would be prohibitive.
Furthermore, DRM isn't a topic without contention. Many groups, including the Electronic Frontier Foundation, have taken issue with the whole concept of digital rights management. One main concern is the prevention of fair use, a concept that exists in copyright law and is seen as being quietly subverted by new legislation. The fear is that the rights of the majority of honest users are being infringed upon in a manner that . The spotlight doesn't appear to have fallen on OMA DRM yet, although that is likely when the deployment of DRM on mobile devices increases.
OMA DRM version 2.0 has passed part 1 of the OMA certification process. Version 2.0 will add, among other features, public key and private key cryptography for protecting the symmetric keys involved with 1.0-combined and separate delivery. If the device has a private key held on the hardware, it will be considerably harder for someone attempting to break the protocol to reuse the rights object on another device. Effectively, the rights object becomes much harder to steal from the device.
Another major consideration is that version 2.0 technologies will become involved in the Content Management License Administrator (CMLA). This primarily means that the possibility of a misbehaving DRM agent is greatly reduced. The idea is that a DRM agent will have been issued with a digital certificate issued by the CMLA, which in turn is used to sign a request for rights. The rights issuer validates the certificate and the request for a rights object and only issues the rights if the requestor is trusted and, therefore, unlikely to misbehave by rendering the content without a watermark or to an unencrypted format. It is also likely that DRM agents will have to go through some validation process to ensure their implementations are correct.
- Get better acquainted with the Open Mobile Alliance, whose mission is to define standards that benefit everyone involved in the creation, provision, and delivery of mobile data-centric services.
- See the OMA's press release announcing DRM Version 2.0, which summarizes the next step in delivering premium content to consumers through wireless media devices.
- Also find out more about OMA's work and specs within their publicly available documents. See also the overview of the OMA release program.
- The Electronic Frontier Foundation was organized to defend intellectual property; find out what's law and what's fair.
- The Content Management License Administrator was also mentioned in this article. Find out what they've been involved in.
- A helpful further look into messaging can be found in Mobile P2P messaging (developerWorks, December 2002).
- You might also read through this column on Mobile Software Tamper Detection (developerWorks, July 2002).
Max Kington is an engineer at Flytxt Ltd., an ASP that supplies systems with mobile and multimedia content and short messaging services. In the last five years, Max has worked in investment banking, mobile technology, and online gaming. His keen interests are cryptography, financial engineering, and scuba diving. He is based in London and can be reached at max.kington@flytxt.com.
