Starting from S60 Third Edition, the File API implementation supports accessing OMA DRM 1.0 protected files (see the specification on the Open Mobile Alliance Web site).
When accessing DRM protected files, the MIDlet has to specify whether
the file is opened in decrypted or in encrypted mode. The DRM access mode
is specified as a parameter at the end of the file URL. If the DRM access
mode is not specified when opening a DRM protected file, java.lang.SecurityException will
be thrown. The syntax for the DRM access mode parameter is as follows:
drm_access_mode :== "?drm=" ( "enc" | dec ) dec :== "dec+" purpose [ "+preview" ] purpose :== "display" | "play" | "print" | "execute"
For examples on URLs containing access mode parameters, see sections Encrypted mode and Decrypted mode below.
DRM protected files can only be opened as read-only. In particular,
this means that MIDlets that want to open DRM protected files must use two
or three-parameter versions of Connector.open(). The
second parameter of the method can only be Connector.READ.
Any other value of the second parameter causes java.lang.SecurityException to
be thrown. If a URL with DRM parameters is passed to the one-parameter version
of Connector.open(), java.lang.SecurityException is
thrown. This is because the default access mode for the one-parameter version
of Connector.open() is Connector.READ_WRITE.
MIDlets can use encrypted mode to read DRM protected files in encrypted form, thus enabling MIDlets to pass DRM protected content from files to other APIs.
When a MIDlet opens a file using a URL that starts with file:// and
ends with “?drm=enc”, this is interpreted as a request
to open a file for reading of the content in the encrypted form. Here is an
example of such a URL:
file:///E:/images/cat.jpg?drm=enc
Rules for the encrypted mode are as follows:
The only supported operation is reading of the file’s content using a stream. It is not possible for a MIDlet to write anything into a file opened in the encrypted mode. Also, it is not possible for a MIDlet to use any other mechanisms except streams for reading of the file’s content.
If an object to which an encrypted mode URL points is an
OMA DRM protected file and the security policy of the mobile device allows
the MIDlet to access this file, the implementation opens the file in the encrypted
mode. This means that in all subsequent read operations, the implementation
returns content as is (i.e. starting with DCF headers continuing with the
encrypted file data). If the security policy of the mobile device does not
allow the MIDlet to access a protected file, java.lang.SecurityException is
thrown by an API method into which the URL was passed
If an object to which an encrypted mode URL points is an
unprotected file, java.lang.SecurityException is thrown
by an API method into which the URL was passed.
Decrypted mode is available only for MIDlets that belong to the manufacturer security domain.
When a MIDlet tries to open a file using a URL that starts with file:// and
ends either with “?drm=dec+’purpose’” or with “?drm=dec+’purpose’+preview”
(where ‘purpose’ is one of the following: "display", "play", "print", or "execute"), this is interpreted by the implementation
as a request to open the file for reading of the content in plain text format.
Here are examples of such URLs:
file:///E:/images/cat.jpg?drm=dec+play
file:///E:/sounds/mew.mp3?drm=dec+play+preview
file:///E:/sounds/mew.mp3?drm=dec+display
Rules for the decrypted mode are as follows:
If an object to which a decrypted mode URL points is an OMA
DRM protected file and the security policy of the mobile device allows the
MIDlet to access this file, the implementation checks the following. Each
decrypted mode URL contains the ‘purpose’ parameter: "display", "play", "print" or "execute". The implementation interprets the value
of this parameter as an indication of an operation that a MIDlet is going
to perform on a file being open. The implementation uses this parameter to
check whether a corresponding OMA DRM permission exists for a given file and
is valid. If a protected file does not have a valid permission for an indicated
operation, the file is not opened and java.lang.SecurityException is
thrown.
For example, if a URL is file:///E:/sounds/mew.mp3?drm=dec+display,
the file has to have a valid "display" OMA DRM permission,
otherwise an exception will be thrown.
If all checks described
above are passed, the implementation opens the file in the decrypted mode.
This means that in all subsequent read operations performed by the MIDlet,
the implementation returns decrypted content. In other words, from the MIDlet
point of view, read operation happens as if the content were not protected.
If the security policy of the mobile device prohibits the MIDlet from accessing
the protected file, java.lang.SecurityException is thrown
by an API method into which the URL was passed.
If an object to which a decrypted mode URL points is an unprotected
file and the security policy of the mobile device allows the MIDlet to access
this file, the implementation opens the file as is. If the security policy
of the mobile device prohibits the MIDlet from accessing the unprotected file
requested using a decrypted mode URL, java.lang.SecurityException is
thrown by an API method into which the URL was passed. Also, in case of an
unprotected file, all URL parameters (e.g., “?drm=dec+display”)
are ignored.
If a decrypted mode URL ends with “preview” and points to
a OMA DRM protected file, this is interpreted by the implementation as an
indication that the MIDlet is not going to consume the content of the file(s).
In this case, if the protected file(s) has the <count> constraint
in a relevant permission, the counter is not decreased. Such behavior is necessary
because in certain situations a MIDlet needs to manipulate the file, but this
manipulation does not qualify for actual consumption of the file’s content.
E.g., a MIDlet may want to display a thumbnail of a protected image. Note,
however, that if in a relevant OMA DRM permission the <count> constraint
is equal to ‘0’, access to a requested file is not granted.
Table below presents availability of different access modes in different security domains when accessing files through File API.