Just An Application

December 17, 2009

What’s New In MIDP 3.0: Redux – Security For MIDP Applications

Filed under: Java, JME, MIDP, MIDP Security, MIDP3, MIDP3Issues — Tags: , , , , , — Simon Lewis @ 12:35 pm

Changes Since Proposed Final Draft

The Security For MIDP Applications chapter, now only available as chapter six of the PDF version of the documentation, has acquired an entirely new section entitled Combined usage of MIDP 2.0 and MIDP 3.0 security models

This states that a MIDP 3.0 MIDlet Suite can use both the new

  • MIDlet-Permission-<n>, and
  • MIDlet-Permission-Opt-<n>

attributes, and the legacy MIDP 2.0

  • MIDlet-Permissions, and
  • MIDlet-Permissions-Opt

attributes.

Similarly a LIBlet can use the use

  • LIBlet-Permission-<n>, and
  • LIBlet-Permission-Opt-<n>

attributes, and the newly defined

  • LIBlet-Permissions
  • LIBlet-Permissions-Opt

attributes.

This addition is presumably motivated by the fact that currently the vast majority of auxiliary MIDP compliant JME JSRs have not been updated to define fine-grained permissions for use with MIDP 3.0.

Issues

Underspecification

The new section says nothing more than that the attributes can all be used together. As such the feature is a tad underspecified. There are a number of possible use cases which need to be addressed. For example

  1. Can a MIDP 3.0 MIDlet Suite use only the legacy attributes ?

  2. Can a MIDP 3.0 MIDlet Suite use named permissions to request fine-grained permissions ?

Runtime Named Permission Checking

Although a MIDP 3.0 MIDlet Suite can now request named permissions, as the specification stands, at runtime, a MIDlet contained in such a MIDlet Suite has no way of checking the named permissions since it cannot use the deprecated MIDlet.checkPermission(String) method. The specification still
states that

For MIDP 3.0 applications, calling checkPermission throws an exception.

Legacy MIDlet Suites Can Use Either Pair Of Attributes But Not Both

The section entitled Security for MIDP 2.x MIDlet Suites, which is now only available as Section 9.2.2 of the PDF version of the documentation has not been changed.

It still states that

  • If there exists one or more instances of the MIDlet-Permission-<n> or MIDlet-Permission-Opt-<n> attribute in the JAD or JAR Manifest, then the Permission classes associated with these attribute values MUST be used, and any instances of MIDlet-Permissions or MIDlet-Permissions-Opt MUST be ignored.

  • If there exists no instances of MIDlet-Permission-<n> or MIDlet-Permission-Opt-<n> attribute in JAD or JAR Manifest, then the following MIDP 2.0 specific attributes MUST be processed when they appear in the JAD or JAR Manifest :

    • MIDlet-Permissions — attribute contains a list of one or more permissions. Multiple permissions are separated by a comma (Unicode U+002C). Leading and trailing whitespace (Unicode U+0020) and tabs (Unicode U+0009) are ignored. The permissions are critical to the function of the MIDlet suite and it will not operate correctly without them.
    • MIDlet-Permissions-Opt — attribute contains a list of one or more permissions. Multiple permissions are separated by a comma (Unicode U+002C). Leading and trailing whitespace (Unicode U+0020) and tabs (Unicode U+0009) are ignored. The permissions are not critical to the function of the MIDlet suite and it will operate correctly without them.

The motivation for defining this functionality was never entirely obvious. As it stands a MIDP 2.x MIDlet Suite can continue to use named permissions in which case it can also use any MIDP compliant auxiliary JME JSR, or use fine-grained permissions in which case it can only use those MIDP compliant auxiliary JME JSRs which have defined fine-grained permissions. Currently, it is diffcult to see why any developer would make the second choice

Given that an implementation now has to support a hybrid fine-grained/named permission model for MIDP 3.0 MIDlet Suites it is unclear why it cannot support it for MIDP 2.x MIDlet Suites as well. Either that or not allow them to use the MIDP 3.0 permissions in the first place.


Copyright (c) 2009 By Simon Lewis. All Rights Reserved.

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: