原文：http://theoreticlabs.com/dev/api/jsr-135/jsr135_rp.html

Multimedia Security

Addendum to the Mobile Media API (JSR135) version 1.2

Version 1.2 1 March 2006

Preface

This document, Multimedia Security is an addendum to the Mobile Media API (JSR-135) version 1.2 for the Java TM 2 Platform. The specification is aimed for implementations of the Mobile Media API, with the Mobile Information Device Profile, Version 2.0 (JSR-118) and the Connected Device Configuration, Version 1.0 (JSR-36) specification. The above specifications can be found at http://www.jcp.org/jsr/detail/135.jsp, http://www.jcp.org/jsr/detail/118.jsp, and http://www.jcp.org/jsr/detail/36.jsp respectively.

The terminology used herein is defined by the above specifications except where noted.

Who Should use this Document

The audience for this document is the Java Community Process (JCP) Expert Group that defined the Mobile Media API specifications, implementers of the MIDP or CDC/FP and the Mobile Media API, application developers using the MIDP or CDC/FP and the Mobile Media API, service providers deploying MMAPI applications, and wireless operators deploying the infrastructure to support MIDP and CDC/FP devices. This document specifically targets network operators, manufacturers, and service and application providers operating in GSM and UMTS networks.

Scope of this Document

This addendum is informative in a way that implementing profile will specify what security framework is used and how it is implemented. Special interest is on MIDP 2.0 for which it is specified that MMAPI implementations on top of MIDP 2.0 must follow this document. The behavior of the security of a MMAPI implementation for CDC is also specified. The purpose of this document is to:

• Define the security framework for Mobile Media API
• Define the security policy identifiers for the Mobile Media API when used together with MIDP 2.0
• Define the security Permissions for the Mobile Media API when used together with CDC 1.0 or later

References

1. Connected Limited Device Configuration (CLDC)

   http://jcp.org/en/jsr/detail?id=30

2. MobileInformationDeviceProfile(MIDP)

   http://jcp.org/en/jsr/detail?id=37

3. MobileInformationDeviceProfile,NextGeneration(MIDP2.0)

   http://jcp.org/en/jsr/detail?id=118

4. SecurityforGSM/UMTSCompliantDevicesRecommendedPractice.

   AddendumtotheMobileInformationDeviceProfileversion2.0.JSR-118ExpertGroup,Version1.0,Nov5,2002.

   http://jcp.org/en/jsr/detail?id=118

5. MobileMediaAPI,version1.0.

   http://jcp.org/en/jsr/detail?id=135

6. JavaTechnologyforWirelessIndustry(JTWI).

   http://jcp.org/en/jsr/detail?id=185

7. ConnectedDeviceConfiguration1.0(CDC)

   http://www.jcp.org/jsr/detail/36.jsp

1. General

The Mobile Media API (MMAPI) specification does not define a security framework of its own. Rather, implementations of MMAPI are subject to the security mechanisms provided by the underlying profile and configuration, e.g. MIDP 2.0 or CDC. Some methods in MMAPI are defined such that a SecurityException will be thrown when called without the appropriate security permissions from the caller.

An implementation MUST guarantee that:

1. the SecurityException is thrown when the caller does not have the appropriate security permissions to execute the method;
2. the method can be used when the appropriate permissions are granted.

Access to the MMAPI properties that can be queried by System.getProperty(String key) is never security constrained.

2. Security Concerns for Mobile Media API

The security concerns of the MMAPI can be divided into areas of recording, network access and access to local data stores. In order to perform any actions on those areas using MMAPI the application MUST be granted the permission to do so. The mechanism to grant the permission is implementation specific and not in the scope of this document.

2.1 Permissions for recording

Recording in MMAPI include recording of audio and video and capturing of still images with the camera. The security issue in recording is the concern about user's privacy. Application silently accessing recording functionality could be used e.g. to record and distribute private conversations of the user. Therefore methods for recording and image capturing must be granted the appropriate permission.

Permissions for MIDP implementations of MMAPI

MMAPI implementations on the MIDP and compatible profiles must perform the permission checks in these methods:

Permissions for CDC implementations of MMAPI

MMAPI implementations on configurations and profiles that use the fine grained security permissions based on java.security.Permission security checks must include the class javax.microedition.media.PlayerPermission and the methods below must perform permission checks:

2.2 Other Permissions

There are other than media recording related security issues when MMAPI is used. Those issues are related to accessing resources either locally or over the network. Media player can be initialized by a locator pointing to a content that can reside on a network server or it could be on some local storage. Reading data over the network requires use of the network connection that may have security policy in place. An access to a local data storage may have security policies in place as well.

Implementation of MMAPI must follow the security practices that are in place for accessing those resources. For example, when a Player is created to play content on a HTTP server, MMAPI implemented on top of MIDP 2.0 must follow the MIDP 2.0 security practices for network access.

MMAPI implemented on CDC must conform to the security requirements of the CDC configuration. When a locator is used to access media the MMAPI implementation must throw a SecurityException under the same conditions as would an access by the Generic Connection Framework.

Below is a list of MMAPI methods which can throw a SecurityException for non-media related security violations. They can potentially have other than media recording security policies attached to them.

When playback is started one of the methods Manager.createPlayer, Player.realize, Player.prefetch and Player.start must throw the SecurityException if there's no permission to open the connection. Because of the multi-stage initialization of Players it is not possible to specify which method exactly must do that.

Notice that RecordControl.setRecordLocation method also has a security permission for media recording. Therefore, it is possible that this method call can result in two separate security checks.