OMA DRM

From Wikipedia, the free encyclopedia

Jump to: navigation, search
 This article may require cleanup to meet Wikipedia's quality standards. Please improve this article if you can. (November 2008)
This article may require copy-editing for grammar, style, cohesion, tone or spelling. You can assist by editing it now.  (November 2008)

OMA DRM is a Digital Rights Management (DRM) system invented by the Open Mobile Alliance whose members represent the entire value chain, including mobile phone manufacturers (e.g. Nokia, LG, Motorola, Samsung, Sony-Ericsson, BenQ-Siemens), mobile system manufacturers (e.g. Ericsson, Siemens, Openwave), operators (e.g. Vodafone, O2, Cingular, Deutsche Telekom, Orange), and IT companies (e.g. Microsoft, IBM, Sun). In order to ensure interoperability across all implementations the OMA provides in addition to the specifications also test tools for OMA DRM. The OMA DRM group is chaired by Bert Greevenbosch (Fraunhofer IIS) and Byung-Rae Lee (Samsung Electronics).

The scheme is implemented on many recent phones and is intended to be used by mobile content providers to add Digital Rights Management to their products. To date, two versions of OMA DRM have been released: OMA DRM 1.0 and OMA DRM 2.0.

  • OMA DRM 1.0 - Started in November 2002 and approved in June 2004: Basic DRM standard without strong protection. Specifies three main methods: Forward Lock, Combined Delivery (combined rights object / media object), and Separate Delivery (separated rights object + encrypted media object). Forward lock prevents the user from forwarding content such as ringtones and wallpapers on their phone. The content can be distributed using e.g. HTTP or MMS.
  • OMA DRM 2.0 - Started in July 2004 and approved in March 2006: Extension of the DRM 1.0 separate delivery mechanism. Each participating device in OMA DRM 2.0 has an individual DRM PKI certificate with a public key, and the corresponding private key. Each Rights Object (RO) 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 (RI, the entity distributing Rights Objects). During this registration, the device certificate is usually validated against a device blacklist by means of an Online Certificate Status Protocol (OCSP) verification. Thus, devices known to be hacked can be excluded once they try to register with an RI and receive new ROs for content access.
  • OMA SRM 1.0 - Started at September 2005 and approved at January 2008 as a Candidate enabler: The goal of the Secure Removable Media (SRM) Work Item is to define the protection and consumption of digital content and associated usage rights on an SRM. An SRM is a removable media that implements means to protect against unauthorized access to its internal data. Examples of an SRM may be the secure memory card and the smart card.The SRM Work Item will not stand-alone; it must be interpreted in the context of the existing OMA DRM v2 suite of specifications. While OMA DRM v2 defines a general framework for downloading Rights to Devices and sharing Rights in a domain, the SRM Work Item will define mechanisms and protocols of the SRM to extend OMA DRM version 2.0 or 2.1 to allow 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 SCE 1.0 - Started at September 2005 and approved at December 2008 as a Candidate enabler: The goal of the Secure Content Exchange (SCE) work is to extend OMA DRM v2.0 to enable seamless sharing of purchased content between multiple devices, including all the devices owned by a subscriber (phone, PC, home electronics system, car audio system, etc) and the temporary sharing of content on any device that is in close proximity to the subscriber’s device (e.g., a television set at a friend’s house or in a hotel room while the user is travelling). Because there will be no single DRM system deployed across all these different devices, the SCE work will also enhance the interoperability between OMA and non-OMA DRM systems by defining an Import function for OMA DRM.

Contents

[edit] Implementations and usage

OMA DRM 1.0 has been implemented in over 550 phone models. Many mobile operators (e.g. Vodafone, SFR, Turkcell, Vivo, Orange) use OMA DRM for their content services. The first OMA DRM 2.0 implementations were released in early 2005 and on mobile phones end of 2005. Software implementations for PC 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. Unlike with digital music stores such as iTunes the record industry does not mandate that DRM be implemented on ringtones. Many ringtones are reverse engineered by the ringtone provider themselves so it is their choice whether to implement the DRM.

[edit] Broadcast Services Security issues with DRM Profile

Broadcast services requirements being completely different from VOD, OMA BCAST Smartcard profile has been recommended by all the industries to be the unified standard used for Mobile TV broadcast.

Commercial OMA DRM providers include:

An open source solution for OMA DRM 2.0 is also available:

The OMA DRM specification uses a Profile of the Open Digital Rights Language for expressing its Licenses:

Since 2006, OMA has been working on DRM 2.0.1 and 2.1, and on new features such as SRM (Secure Removable Media) and SCE (Secure Content Exchange)

[edit] Determining that a file is OMA protected

On Nokia Series 40 phones an installed file with DRM will not have its "Send" option greyed out in its options menu. If the user attempts to send this via MMS a message "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 (eg. music track) is received with separate delivery - the key is sent async with the actual download of the file and the file contains a licens 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.

[edit] Criticism

Some vendors are too vague with their implementations of DRM schemes, often restricting legal consumer rights beyond scope documented by OMA DRM standards. This usually conducted without issuing any special warnings about DRM schemes used and restrictions which are in effect so consumers can't get aware of such 'features' before it is too late. For example some Nokia's Symbian-based devices (at least Nokia 6680, 6681 and probably many others) will completely refuse to send all files of certain types over Bluetooth. For mentioned phones this 'feature' at least completely blocks sending of *.mid, *.jar, *.sis and *.jad files regardless of fact if file has been protected by any DRM scheme or not and which licenses cover specific file usage. Such phones will refuse any attempts to send any mentioned files with message "Unable to send protected objects" or similar. Unfortunately this also means that you can't send even content where license explicitly allows redistribution and even welcomes it. For example, such phone will refuse to send any GPLed Symbian programs or Java applets just as any other file, effectively voiding your legal rights granted by licenses. Nokia site does not directly warns that such frustrating 'features' are built-in so you have to buy phone first and only then you can get aware of such 'features' but then it is usually a bit late to backpedal. Some consumers believe that such vendor behavior does not qualifies as fair business practices.

There are a few ways to relax these undocumented DRM restrictions imposed by Nokia on their own (i.e. outside of OMA DRM scope):

  • You can rename *.mid files into *.midi files, actually *.midi is a full name of *.mid file format. While *.midi is still recognized by most cell phones as MIDI file and phone itself is willing to play it as MIDI, *.midi is not forbidden to send so restriction could be bypassed. Of course this will work only for regular MIDI files which were not 'protected' by OMA DRM schemes so if you're aware that certain file license allows it's distribution or you're going to exercise in fair use rights you can send such file anyway.
  • You can temporarily rename *.jar and *.sis files into some different extension with 3rd party file managers and then you can send it over Bluetooth. Upon reception you can rename such file back to original extension, effectively bypassing restrictions.
  • If you have another device with Bluetooth, it supports Bluetooth FTP profile and it has Bluetooth FTP client built-in, you can browse phone filesystem content. Nokia's Bluetooth FTP server side ignores mentioned limitations so you can access your files from another paired device over Bluetooth. Some devices are even able to fetch file over Bluetooth FTP and then re-send it over usual Bluetooth push method at once, acting as a some sort of Bluetooth proxy.

[edit] External links

Retrieved from "http://en.wikipedia.org/wiki/OMA_DRM"
Personal tools
Languages