Oct. 1, 2009, 8:44 p.m.
posted by barateon
18.3 Trusted MIDlet Suite Security ModelToday, many functions are provided by applications built into the device. Trust in the applications comes from trust in the device manufacturer and network operator who are clearly identified. Consumers also need to know and trust downloadable applications and their sources. The MIDP Specification version 2.0 introduces the concept of trusted MIDlet suites, which provides a level of authentication that allows the users to have such confidence. A trusted MIDlet suite is one for which the source, authenticity, and integrity of the JAR can be reliably determined by the device. The procedure for determining whether a MIDlet suite is trusted is device-specific. Some devices might trust only MIDlet suites obtained from certain servers. Other devices might support only untrusted MIDlet suites. It is also possible for a device to authenticate MIDlet suites with the same strong security mechanisms that web sites rely on everyday: the Public Key Infrastructure (PKI). See Section 18.5, "Establishing Trust for MIDlet Suites by Using X.509 PKI," for more information. Once the device trusts the MIDlet suite, it can grant the MIDlets in the suite permission to use protected functions. Determining whether to grant a requested permission is known as authorization. 1 PermissionsDevices use permissions to protect access to APIs or functions that require authorization before being invoked. The permissions described in this section refer only to those APIs and functions that need security protection. They do not apply to APIs that do not require authorization and can be accessed by both trusted and untrusted MIDlet suites. (Section 18.4, "APIs That Are Not Security Sensitive," covers the non-security-sensitive APIs.) A MIDP implementation typically gives trusted applications more access to security-sensitive APIs than untrusted MIDlets. To ensure that access is granted appropriately, the implementation checks permissions prior to each invocation of a protected function. MIDlet suites must have their permission request granted before the implementation provides the function. Figure summarizes the permissions that apply to the restricted APIs.
Permission NamesThe names of permissions are case-sensitive and have a hierarchical organization similar to package names in the Java™ programming language. The names of the permissions for an API must begin with the package name of the API. If the permission is for functionality provided by a specific class in the package, then the permission must begin with both the package and class names. Any additional modifiers may be appended after a period (.) separator. The set of valid characters for permission names is the same as the set for package and class names. Permission names should use the same conventions for capitalization as package names. For example, javax.microedition.io.Connector.datagram is the permission that protects the use of datagram functionality. As the permission name indicates, the class javax.microedition.io.Connector (a static factory class for creating new connection objects) provides the datagram connection. The class also provides connection objects for other protocols, hence the period followed by the modifier datagram in the permission name. Creating New PermissionsEach API that provides access to protected functionality defines its own permissions. The MIDP Specification version 2.0 defines permissions for its protected APIs. APIs defined outside of the MIDP Specification version 2.0 must have a single document that specifies any necessary permissions and the behavior of the API when it is implemented for MIDP 2.0. 2 Requesting Permissions for a MIDlet SuiteA MIDlet suite might require access to some protected APIs or functions and consider access to others optional. A MIDlet suite that requires access to protected APIs or functions must request the corresponding permissions by listing them in the MIDlet-Permissions attribute of its JAR manifest or application descriptor (JAD). A MIDlet should list permissions using this attribute only if the permissions are critical to the function of the MIDlet suite (that is, the MIDlet will not operate correctly without them). A MIDlet suite that can use protected APIs, but can function correctly without them, should request the corresponding permissions by listing them in the MIDlet-Permissions-Opt attribute of its JAR manifest or application descriptor. The MIDlet suite should be able to run with reduced functionality without these non-critical permissions. For example, perhaps the user can play a game MIDlet as a single-player game if the permissions cannot be granted, instead of as a network-aware game. For example, to require permission to be launched for an alarm (a PushRegistry function) and to conditionally require a SecureConnection, a MIDlet suite would use the following attribute-value pairs in its JAR manifest or application descriptor: MIDlet-Permission: javax.microedition.io.PushRegistry MIDlet-Permission-Opt: javax.microedition.io.Connector.ssl Multiple permissions are separated by a comma. Leading and trailing white space and tabs are ignored. 3 Protection DomainA protection domain defines a set of permissions and related interaction modes. (See Section 18.3.4, "Interaction Modes for User Permissions," for more information.) A device places each MIDlet suite into a protection domain. The domain's permissions are the only permissions that the device can grant to the MIDlets of the suite. For example, Section 18.2, "Sandbox for Untrusted MIDlet Suites," covered the access rights in the untrusted domain. A protection domain consists of permissions that are either:
18.3.4 Interaction Modes for User PermissionsA User permission requires the user to either deny permission to use a specific API or function or to grant permission by choosing one of the following interaction modes:
The security policy of the device implementation determines the choice of interaction modes for user permissions. The policy defines, for each user permission, the default interaction mode and a set of other interaction modes from which the user may choose. The implementation may offer the user the default interaction mode if it is supplied. 5 Granting Permissions to Trusted MIDlet SuitesThe process of authorizing a MIDlet suite is established by the relationships between:
To authorize a trusted MIDlet suite, the MIDlet suite must be in a protection domain. In addition, the MIDP implementation must have gotten the critical and non-critical permission requests from its JAR manifest or application descriptor, and must remove from consideration any non-critical permissions that are unknown to it. The permissions that can be granted to the MIDlet suite are the intersection of the requested permissions with the union of the Allowed and user-granted permissions in the protection domain. A MIDP implementation authorizes a MIDlet suite for the first time when the user tries to install it. The MIDlet suite must meet the following authorization requirements, or it will not be installed:
A MIDP implementation also authorizes a MIDlet suite when it tries to access a protected API. (During execution, protected APIs must check for the appropriate permissions.) If the MIDlet's protection domain protects the security-sensitive API with a User permission, the user must provide authorization in order to grant those permissions to the MIDlet suite. The MIDP implementation is responsible for making the request to the user and getting the response to allow or deny the request. When the implementation prompts the user, it should provide a description of the requested permissions that is clear enough to enable a well-informed choice. The user must always be able to deny permission. The result of a successful authorization is that the MIDlet suite is granted access to the protected API. If the permission was not granted, the protected API must throw a SecurityException. |
- Comment