Permission controls a single protected
function, for example javax.microedition.io.Connector.http provides control over HTTP connections.
Represents a collection of protected functions. For
example Network Access encapsulates a set of
network connectivity related permissions. Function groups are used
to make the protected functions visible to end user in a convenient
way, rather than exposing single permissions. Application access to
a function group can be of type Allowed, User or No:
Allowed - access is granted without need
to interact with device user
User - end user acceptance is required
prior to accessing protected function
No - access is explicitly denied without
need to interact with device user
Note: MSA 248 recommends a set of function groups that compliant devices are expected to support. It is up to device vendor to decide whether to adhere to recommendation.
When access to function group is of type User, there are three different interaction modes defined:
Blanket (Always allowed) - permission
is not asked from end user
Session (Ask first time) - permission
asked from end user once during application execution
Oneshot (Ask every time) - permission
asked from end user every time certain sensitive operation is accessed
The device implementation can provide the end user with the possibility to configure interaction modes, within limits defined by the security policy. Nokia Asha software platform devices and Series 40 provides the possibility to configure interaction modes. For more information, see Managing security settings.
Represents the level of trust a device has for the application. The device naturally can trust applications from the device vendor more than ones coming from unknown sources. MIDP 2.1 and MSA 248 recommend that Java ME implementations support at least the following protection domains:
Manufacturer
Operator
Identified 3rd Party
Unidentified 3rd Party
Note: Only the Unidentified 3rd Party domain is mandated. Others domains can exist and there can also be additional domains specified in a device.
Each protection domain has one
or more Root Certificates associated with them. Root Certificates represent Certificate Authorities supported and trusted by the device. Root Certificate cannot be associated to more than one protection domain at a time.
Root Certificates are used to verify digital signatures of installed
applications and to bound them to appropriate protection domain. For
example an application signed by a mobile operator is bound to the Operator domain, whereas an application signed via a
3rd Party CA, for example JavaVerified program is bound to Identified
3rd Party domain.
Digital signing is the tool to determine whether an application originates from an authentic source or not. MIDP specifies digital signing based on X.509 PKI. Java Runtime for Nokia supports X.509 PKI as specified by MIDP, no other signing schemes are supported.
Trusted applications are digitally signed and their integrity and origin can be verified by the device. Trusted applications have more privileges, they operate more freely without asking end user permission.
Untrusted applications are not digitally signed and come from an unknown source. They are bound to Unidentified 3rd Party protection domain which normally is the least privileged domain.
Security policy defines the supported set of protection
domains. Each protection domain defines the set of function groups
available and defines whether function group accessibility is of type Allowed, User or No. In case of User the default interaction mode
is specified, but the end user can also select the interaction mode
from a range of options, if the device supports the functionality.
Note: MSA 248 defines a default security policy recommended for devices that comply with MIDP 2.1 and MSA 248 specifications. It is up to the device vendor whether to adhere to the recommendation or not. For more information, see MSA security policy.
For more information about MIDP security, see the following links:
Chapter 3 - Security for MIDP applications
Chapter 4 - Trusted MIDlet Suites using X.509 PKI
Chapter 15 - The Recommended Security Policy for GSM/UMTS Compliant Devices
Chapter 7.3 - Security Requirements
Appendix 4 - Security Permissions and Function Groups