Oma drm V1.0 learning notes

The definition of DRM in OMA is mainly to provide content providers with a method to control the use of media objects, this includes previewing DRM messages, protecting files, preventing illegal copies, and super transmission (a valid copy method ).

 

 

 

 

To ensure the legal use of media objects within the DRM scope, once an object is downloaded, it is taken over by the DRM agent (usually running on a mobile terminal to implement DRM control.

The DRM system allows content providers to add different copyrighted objects to different media objects, and the same media object can also be added with different copyrighted objects, content Providers can set prices based on different copyright objects, and customers can purchase resources based on pricing. Therefore, a reasonable electronic consumption system is generated. Content providers provide users with copyrighted objects to preview DRM messages. Some wonderful previews tend to attract more consumers.

It should be understood that both the copyright object and the media object can be viewed as objects, and the protected media object can be easily obtained, but the copyright object must be purchased separately. A copyrighted object can be used to play protected media objects.

There are three methods to obtain copyright objects and media objects:

 

The first two methods are: Forward-lock, that is, forwarding lock; combined delivery, that is, combined sending. Both methods need to package the media file. If you use the second method, you also need to package the copyright object and media file in one file. The DRM agent plays media Objects Based on the copyright object. If the media objects do not contain the copyright object, the media objects are played based on the default copyright set in the DRM agent.

The third method is separate delivery, that is, Group Sending. For details, see. Pack the media object into the DCF (DRM content format) format specified in oma drm V1.0 and encrypt it with a symmetric key. To play a media file, only the CEK (content encryption key) is obtained for decryption. Therefore, when transferring DCF files, you can use a low-security communication mode. When transferring copyrighted objects and CEK, you need a high-security mode ., In analyticdb 1.0, you can use text message push to send copyright objects to mobile terminals.

 

According to Group Sending, oma drm V1.0 puts forward the concept of super distribution. The DCF file can be transferred between multiple mobile terminals, but the copyright object cannot be transferred. When a mobile terminal that does not contain a copyright object receives the DCF file, it will access the corresponding copyright Object Server according to the definition in the file, prompting the user to purchase and download the corresponding copyright object. See.

 

The formats of media objects to be supported by mobile terminals that support forwarding locking are:
Application/vnd. oma. DRM. Message.
The format of media objects to be supported by mobile terminals that support the combined transmission mode is as follows:
Application/vnd. oma. DRM. Message, application/vnd. oma. DRM. Rights + XML
The format of media objects to be supported by mobile terminals that support sending by group is as follows:
Application/vnd. oma. DRM. Content, application/vnd. oma. DRM. Rights + XML,
Application/vnd. oma. DRM. Rights + wbxml

Forwarding lock:
In the forwarding lock mode, the mobile terminal prohibits the forwarding of DRM messages (DRM messages are the files generated after media objects are packaged, but they are not encrypted and are stored in plaintext ). The DRM message file format must be supported. If the mobile terminal receives a DRM message containing the copyright object (in the combined sending method, the processing object is the DRM message containing the copyright object), after prompting the user, discard the DRM message. A mobile terminal can play media objects, but cannot modify them.

Combined sending:
A mobile terminal that supports the combined transmission mode must support the forwarding lock mode. In this mode, the mobile terminal plays media Objects Based on the copyright object. The copyrighted object and media object are encapsulated in the same DRM message. For these two objects, their associations are external. Therefore, the mobile terminal must ensure that the copyright object is permanently saved when the DRM message is received and may be discarded after unpacking. The mobile terminal cannot forward media objects in the combined transmission mode. When a mobile terminal uses the downloaded content, it must follow the description in the description language "rights Expression Language" of the copyright object. Rel controls the use of the downloaded content, for example, whether the downloaded media object can be opened only once.

Send by group:
The DRM agent that supports Group Sending must support combination sending and forwarding locking. In group sending, media objects are usually encrypted and converted to the DCF format. The DCF file is downloaded to the device through the Oma download method, and the Copyright object is delivered through other ways (wap push ). In Group Sending, devices are allowed to forward the DCF file, but the copyrighted object cannot be forwarded. Other devices receiving the DCF file must obtain the copyrighted object from right issuer. The mobile terminal must support both the copyright and DRM content format (DCF) media types.

In oma drm 1.0, the rule on Streaming Media support is very simple, which is almost the same as not mentioned, so we will not introduce it.

In the forwarding lock mode, the server returns the DRM message

HTTP/1.1 200 OK
Content-Type: Application/vnd. oma. DRM. message;
Boundary = boundary-1
Content-Length: 574
-- Boundary-1
Content-Type: image/JPEG
Content-transfer-encoding: Binary
...Jpeg image in binary format...
-- Boundary-1-

In combination, the server returns the DRM message

HTTP/1.1 200 OK
Content-Type: Application/vnd. oma. DRM. message;
Boundary = boundary-1
Content-Length: 893
-- Boundary-1
Content-Type: Application/vnd. oma. DRM. Rights + XML
Content-transfer-encoding: Binary
<O-EX: Rights
Xmlns: O-Ex = "http://odrl.net/1.1/ODRL-EX"
Xmlns: O-dd = "http://odrl.net/1.1/ODRL-DD"
>
<O-EX: context>
<O-DD: version> 1.0 </o-DD: version>
</O-EX: context>
<O-EX: agreement>
<O-EX: asset>
<O-EX: context>
<O-DD: uid> CID: 4567829547@foo.bar </o-DD: uid>
</O-EX: context>
</O-EX: asset>
<O-EX: Permission>
<O-DD: Display/>
</O-EX: Permission>
</O-EX: agreement>
</O-EX: rights>
-- Boundary-1
Content-Type: image/JPEG
Content-ID: <45678929547@foo.bar>
Content-transfer-encoding: Binary
...Jpeg image in binary format...
-- Boundary-1-

DRM message returned by the server in the Group Sending Method

HTTP/1.1 200 OK
Content-Type: Application/vnd. oma. DRM. content;
Content-Length: 1234
X-OMA-DRM-separate-delivery: 12
... DRM content in DCF format...

Original article: http://blog.csdn.net/jiyucn/archive/2007/06/29/1671656.aspx