Security
JSR 272 security concerns two different areas:
1. The security of the running application
Some methods defined in JSR 272 are protected by security.
If an application had not acquired the adequate rights or permissions
to invoke these methods, a SecurityException will
be thrown.
Security of method javax.microedition.broadcast.recording.RecordingScheduler.setRecordDirectory(String) must
be handled as in FileConnection.setFileConnection(String).
For APIs that are referenced but are not defined within this specification,
for example, JSR 135 and JSR 234, any security permissions pertaining
to them are defined in their respective specifications and must be followed.
Some methods in JSR 272 can throw SecurityException because of DRM. Those methods
are not addressed in this section since user can not give permission to pass DRM.
2. Permissions for MIDP based implementations
The following table defines the permissions associated with
all the security-protected methods when this specification
is implemented on top of MIDP. As such, it follows the
MIDP security model.
3. Permissions for CDC based implementations
Implementations using security permissions based on java.security.permission must include class
javax.microedition.broadcast.BroadcastPermission which extends
java.security.BasicPermission and the methods below must perform permission checks.
|
API call
|
Action in javax.microedition.broadcast.BroadcastPermission
|
javax.microedition.broadcast.recording.RecordingScheduler.add()
javax.microedition.broadcast.recording.RecordingScheduler.remove()
|
"recordingScheduler.add"
"recordingScheduler.remove"
|
javax.microedition.broadcast.recording.RecordingScheduler.addListener()
javax.microedition.broadcast.recording.RecordingScheduler.findRecording()
javax.microedition.broadcast.recording.RecordingScheduler.getAllPreferenceKeys()
javax.microedition.broadcast.recording.RecordingScheduler.getPreference()
javax.microedition.broadcast.recording.RecordingScheduler.getRecordDirectory()
javax.microedition.broadcast.recording.RecordingScheduler.listRecordings()
javax.microedition.broadcast.recording.RecordingScheduler.setPreference()
|
For all methods
"recordingScheduler.access"
|
javax.microedition.broadcast.esg.ServiceGuide.getAllServiceGuides()
javax.microedition.broadcast.esg.ServiceGuide.getDefaultServiceGuide()
|
For all methods
"serviceGuide.access"
|
javax.microedition.broadcast.ServiceContext.createServiceContext()
javax.microedition.broadcast.ServiceContext.getDefaultContext()
javax.microedition.broadcast.ServiceContext.select()
|
"serviceContext.create"
"serviceContext.default"
"serviceContext.select"
|
javax.microedition.broadcast.purchase.SubscriptionManager.getSubscriptions()
javax.microedition.broadcast.purchase.PurchaseObject.purchase()
javax.microedition.broadcast.purchase.PurchaseObject.cancel()
|
"subscriptionManager.getSubscriptions"
"purchaseObject.purchase"
"purchaseObject.cancel"
|
javax.microedition.broadcast.ServiceContext.getBroadcastDatagramConnection()
|
"serviceContext.getBroadcastDatagramConnection"
|
javax.microedition.broadcast.ServiceContext.getBroadcastDatagramConnection()
|
"broadcastfile.read"
|
4. The security for downloaded applications
JSR 272 provides the possibility to install and launch applications which are
delivered by the broadcast stream. In these cases, the security mechanisms
of the underlying platform to manage installation and launching of applications
will apply.
DRM
If a Service (or a ProgramEvent) is protected (metadata attribute
SERVICE_IS_PROTECTED or
PROGRAM_IS_PROTECTED
is true), a Rights Object (RO thereafter) is needed to decrypt the protection before the service can be consumed.
Service that is protected can still be free. For free services the RO will be fetched automatically by the implementation.
For non-free services the rights must be bought if they haven't been purchased already.
A RO contains attributes and constraints, which specify
what the terminal can do with the content. For instance, OMA DRM has the following
possible action rights PLAY, EXECUTE, EXPORT, ACCESS and additional
constraints on count, timed-out, date time, interval, accumulated, viewing times.
JSR 272 is agnostic to the technical implementations of the rights management (DRM)
and to the RO delivery mechanism to the device. In the following example
architecture, the Broadcast Service Implementation enforces the rights
in the Presentation/Recording Engine.
JSR 272 provides operations to record A/V content received from the broadcast
channel. However, the recording may be restricted by RO rules. In such cases,
the media Player object does not provide a RecordControl.
Like recording, the sharing of the content may be restricted by the RO rules.
Content that cannot be shared shall not be accessible by the application directly
as raw data.
The application can still play back the content by controlling the
Player object obtained from ServiceContext.
See the recording section
for more information on recording support.
The current version of the JSR 272 specification does not provide any mechanism
to directly access the ROs for detail information.
Purchasing
Purchasing in JSR 272 specifies the interfaces to allow the user to buy rights to consume mobile digital television content.
JSR 272 does not specify the exact process to get the rights and the billing mechanism. Those are
implementation specific depending on the underlying technology and service provider etc. JSR 272 does provide the high level
interface to perform the purchase transactions. Purchasing via JSR 272 always requires user attendance; the application can
not purchase services without the user's approval.
Overview
Purchasing in JSR 272 is based on
- Purchase bundles. Purchase bundle is an entity containing a set of services or program events that can be purchased
for some price. A bundle may contain same services and program events from some other bundles.
- Services. Purchasing a service means purchasing a single service; or a bundle that contains the requested service if the
requested service can only be purchased as part of a bundle.
- Program eventes. Purchasing a program event means purchasing the individual program event; a service the program event belongs to; or
a bundle that contains the requested program event or service if the program event or service cannot be purchased individually.
In all cases, the bundling of program events and services into bigger entities is done by the service provider. JSR 272 enables
purchasing of individual program events and services. But it is up to the service provider whether it can be done in reality.
Application can query the purchased services, subscriptions, and cancel them. The API details for purchasing are described in
SubscriptionManager. Examples about the use
of the purchasing functionality can be found in purchasing examples
Security
JSR 272 has two layers. Firstly, the security framework can be used to prevent application's access to methods performing the purchase
or cancellation of a subscription.
Secondly, when purchasing or cancel of subscription is initiated, the implementation will pop up a dialog to confirm the transaction,
similar to the way the security framework prompts permissions from the user. The Java application does not have any control over the popped up dialog.
More information about the JSR 272 security issues can be found in the JSR 272 Security section .
Playing back DRM protected content
This section describes what happens when an application tries to use DRM protected services.
Service to be consumed is normally get from the the ServiceGuide, and selected by
ServiceContext.select(). Services for which the application doesn't have rights can be
successfully selected but if Player.prefetch() is called then
- the method throws
SecurityException and the Player remains in REALIZED state
SubscriptionManager.NO_RIGHTS event is posted to its PlayerListener
ServiceContextListener.CONTEXT_STOPPED event is posted to ServiceContextListener with
a reason code REASON_NO_RIGHTS.
Application can query if a service is protected by
Service s;
// get service from ServiceGuide ...
// ...
boolean protected = s.getBooleanValue(CommonMetadataSet.SERVICE_IS_PROTECTED);
Application can also check if the rights to access the service is free of charge by
boolean free = s.getBooleanValue(CommonMetadataSet.SERVICE_IS_FREE);
For a protected free content the start of the playback may fail if the RO is not available at the device.
SubscriptionManager.RIGHTS_UPDATED event will be sent the PlayerListener when the RO has been successfully
received. ROs may be updated every now and then, and it may be possible to receive SubscriptionManager.RIGHTS_UPDATED
event in the middle of the playback without any other effects, for instance, in the visual output.
For non-free content the application must purchase the rights if not having the already. Continuing the incomplete sample code:
PurchaseObjet[] pos = SubscriptionManager.getPurchaseObjects(s.getStringValue(CommonMetadataSet.SERVICE_ID));
if (pos.length > 0) {
boolean owned = pos[0].isPurchased();
if (!owned) {
// buy if not owned
pos[0].purchase();
}
}
It's possible that Service that is free contains ProgramEvents that are not free.
boolean freeService = s.getBooleanValue(CommonMetadataSet.SERVICE_IS_FREE); // return true
boolean freeProgram = s.getBooleanValue(CommonMetadataSet.PROGRAM_IS_FREE); // return false
Purchasing the rights is done similarly than with Service but PROGRAM_ID is used instead
of SERVICE_ID to get the purchaseObjects.
When a non-free ProgramEvent starts in a free Service or if, for instance, the rights are
expired during the playback, then
SubscriptionManager.NO_RIGHTS event is posted to the PlayerListener
and Player enters into REALIZED state.
ServiceContextListener.NO_RIGHTS event is posted to the ServiceContextListener