OMA DRM is a digital rights management system invented by the Open Mobile Alliance, whose members represent mobile phone manufacturers, mobile system manufacturers, mobile phone network operators, and information technology companies. DRM provides a way for content creators to set enforced limits on the use and duplication of their content by customers. The system is implemented on many recent phones. To date, two versions of OMA DRM have been released: OMA DRM 1.0 and OMA DRM 2.0. In order to ensure that all manufacturers' implementations of OMA DRM can work with each other, the Open Mobile Alliance provides specifications and test tools for OMA DRM. The OMA DRM group is chaired by Sergey Seleznev.
Versions
OMA DRM 1.0
OMA DRM version 1.0 was first drafted in November 2002, and approved in June 2004. It provides basic Digital Rights Management, without strong protection. The standard specifies three main methods: Forward Lock, Combined Delivery, and Separate Delivery. Forward Lock prevents the user from forwarding content such as ringtones and wallpapers on their phone. The content can be distributed using HTTP or MMS.
OMA DRM 2.0
Version 2.0 was drafted in July 2004 and approved in March 2006. The primary new feature is the extension of DRM 1.0's Separate Delivery mechanism. Each participating device in OMA DRM 2.0 has an individual DRM Public key infrastructure certificate, with a public key and the corresponding private key. Each Rights Object is individually protected for one receiving device by encrypting it with the device public key. The RO in turn contains the key that is used to decrypt the media object. Delivery of Rights Objects requires a registration with the Rights Issuer. During this registration, the device certificate is usually validated against a device blacklist by means of an Online Certificate Status Protocol verification. Thus, devices known to be hacked can be excluded once they try to register with an Rights Issuer in order to receive new Rights Objects so they can access the content.
OMA SRM 1.0
Started in September 2005 and approved in March 2009, the goal of the Secure Removable Media Work Item is to define the protection and consumption of digital content and associated usage rights on an SRM. An SRM is a removable medium that implements means to protect against unauthorized access to its internal data, such as a secure memory card or smart card. The SRM Work Item does not stand alone; it extends the existing OMA DRM 2.0 specifications. While OMA DRM 2.0 defines a general framework for downloading Rights to devices and sharing Rights in a domain, the SRM Work Item defines mechanisms and protocols for the SRM. It extends OMA DRM version 2.0 or 2.1, allowing users to move Rights between devices and SRMs, and to consume Rights stored in SRMs without generating and managing complex groups of devices in a domain.
OMA SRM 1.1
Started in December 2008 and approved in June 2011, SRM 1.1 is an extension of SRM 1.0 introducing such functions as content license move between two SRMs, direct license provisioning to SRM and support for OMA Broadcasting tokens. Latter allows to turn SRM into a secure electronic wallet capable to store credits that are used to subscribe to mobile broadcast and multicast services.
OMA SCE 1.0
OMA SCE 1.0 started in September 2005 and was approved in December 2008 as a Candidate enabler. The goal of Secure Content Exchange is to extend OMA DRM v2.0, enabling seamless sharing of purchased content between multiple devices, including all the devices owned by a subscriber and the temporary sharing of content on any device that is in close proximity to the subscriber’s device. Because there will be no single DRM system deployed across all these different devices, the SCE also enhances the interoperability between OMA and non-OMA DRM systems, by defining an Import function for OMA DRM.
Implementations and usage
OMA DRM 1.0 has been implemented in over 550 models of mobile phone. Many mobile operators use OMA DRM for their content services. The first OMA DRM 2.0 implementations were released in early 2005; implementations were installed on mobile phones by the end of 2005. Software implementations for personal computer and PDA clients are also available. Most of the ringtones pre-installed on mobile phones have implemented DRM. Many commercial ringtone vendors who are not part of any mobile phone carrier do not bother with any form of DRM, perhaps because the number of ringtone vendors is huge, and people will choose to download unprotected ringtones if they can get them. The record industry does not mandate that DRM be implemented on ringtones, unlike most digital music stores. Many ringtones are reverse-engineered by the ringtone provider themselves, so it is their choice whether to implement the DRM. Since 2006, OMA has been working on DRM 2.0.1 and 2.1, and on new features such as SRM and SCE.
Broadcast Services Security issues with DRM Profile
Broadcast services requirements being completely different from video-on-demand, the OMA BCAST Smartcard profile has been recommended by all the industries to be the unified standard used for Mobile TV broadcast.
On NokiaSeries 40 phones, an installed file with DRM will have its "Send" option greyed out in its options menu. If the user attempts to send such a file via MMS, a message stating "The file is copyright protected" will appear. A Bluetooth file transfer will fail if the user tries to extract the file using Bluetooth, yet the file will still appear as present, and will still be deletable via Bluetooth. However, if the file is received with separate delivery—the key is sent separately from the actual download of the file, and the file contains a license URL—it is possible to forward the file to other devices. Once the file is activated on the new device, it will prompt the user to access the URL embedded in the file, and give the user the option to acquire the key.
Criticism
Some vendors implement broad DRM systems, restricting consumer rights beyond the scope documented by the OMA DRM standards. For example, some Nokia Symbian-based devices will completely refuse to send all files of certain types over Bluetooth. For these phones, this blocks sending of MIDI files, Java Applets, and Symbian programs regardless of whether or not they are protected by DRM. Such phones will refuse any attempts to send such files with the message "Unable to send protected objects" or a similar error. This prevents sending such content, even when the content license explicitly allows or even depends on redistribution.
