Just An Application

July 31, 2009

What’s New In MIDP 3.0 ? Part 45: Accessing Device And Subscriber Specific Properties

Filed under: Java, JME, MIDP, MIDP3 — Tags: , , , — Simon Lewis @ 6:06 pm

A MIDlet can access device and subscriber specific properties using the System.getProperty(String) method.

Device Properties

  • ESN

  • IMEI

  • MEID

  • PESN

  • UUID

The property name for use with the System.getProperty(String) method can be obtained by prefixing the lower case version of the name with

	microedition.deviceid.

For example,

	microedition.deviceid.uuid

Subscriber Properties

  • IMSI

  • EUIMID

  • ICCID

  • MSISDN

  • UUID

The property name for use with the System.getProperty(String) method can be obtained by prefixing the lower case version of the name with

	microedition.subscriberid.

For example,

	microedition.subscriberid.imsi

Security

To access any of these properties a MIDlet will need to be granted the PropertyPermission with an action of read and a name matching the name of the property being accessed.

The intent of the default security policy appears to be that this permission is not granted to MIDlets in MIDlet Suites bound to the Unidentified Third Party protection domain (aka the domain formerly known as Untrusted).


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

July 25, 2009

What’s New In MIDP 3.0 ? Part 44: The Security Policy And Fine-Grained Permissions

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

1. Mapped And Unmapped Permissions

The default MIDP 3.0 security policy divides the defined fine-grained permissions into those that it maps to function groups, and those that it does not.

The latter it further divides into

  • Allowed

  • Not Allowed

  • Not Permitted

where Not Permitted means a permission

MUST NOT be mapped to any function group, and MUST NOT be available in either the Identified or Unidentified Third Party Protection Domain.

2. The Unmapped Permissions

Omitting the CDC specific permissions the unmapped permissions are

  • java.lang.RuntimePermission

  • java.util.PropertyPermission

  • javax.microedition.event.EventPermission

  • javax.microedition.midlet.ActionsDeniedPermission

  • javax.microedition.midlet.AutoStartPemission

2.1 Manufacturer And Operator Protection Domains

By implication, they are granted all the permissions in function groups, MIDlet Suites bound to the Manaufacturer or Operator protection domains are granted all the unmapped permissions.

Note

    It is not clear whether this would include a RuntimePermission with a target of exitVM. Possibly not ?

2.2 Identified Third Party Protection Domain

2.2.1 ActionsDeniedPermission

The ActionsDeniedPermission is ‘Not Permitted’.

MIDlet Suites bound to the Identified Third Party protection domain cannot use the

    MIDlet-UserDenied

or

    MIDlet-<n>-UserDenied

attributes.

2.2.2 AutoStartPermission

The AutoStartPermission is ‘Not Permitted’.

MIDlet Suites bound to the Identified Third Party protection domain cannot use the

    MIDlet-<n>-Type

attribute with a type of

    autostart

2.2.3 EventPermission

The apparent intention of the security policy is that MIDlet Suites bound to the Identified Third Party protection domain are granted an EventPermission with an action of

  • read for any Event

  • register for any Event

  • post for any non-system Event

but see Issues.

MIDlets in these MIDlet Suites can successfully call

  • the EventManager.getCurrent(String) method for any event.

  • any of the EventManager.addListener() methods for any event

  • any of the EventManager.registerApplication() methods for any event

  • the EventManager.post(EventData) method for any non-system event

and use the

    MIDlet-Event-Launch-<n>

attribute for any event.

2.2.4 PropertyPermission

MIDlet Suites bound to the Identified Third Party protection domain are granted a PropertyPermission with an action of read for any system property, but see Issues.

MIDlets in these MIDlet Suites can use the System.getProperty(String) method to get any system property.

2.2.5 RuntimePermission

The RuntimePermission is ‘Not Permitted’.

2.3 Unidentified Third Party Protection Domain

2.3.1 ActionsDeniedPermission

The ActionsDeniedPermission is ‘Not Permitted’.

MIDlet Suites bound to the Unidentified Third Party protection domain cannot use the

    MIDlet-UserDenied

or

    MIDlet-<n>-UserDenied

attributes.

2.3.2 AutoStartPermission

The AutoStartPermission is ‘Not Permitted’.

MIDlet Suites bound to the Identified Third Party protection domain cannot use the

    MIDlet-<n>-Type

attribute with a type of

    autostart

2.3.3 EventPermission

MIDlet Suites bound to the Unidentified Third Party protection domain are granted an EventPermission with an action of

  • read for any Event

  • register for any Event

MIDlets in these MIDlet Suites can successfully call

  • the EventManager.getCurrent(String) method for any Event.

  • any of the EventManager.addListener() methods for any Event

  • any of the EventManager.registerApplication() methods for any Event

and use the

    MIDlet-Event-Launch-<n>

attribute for any event, but they cannot post any kind of Event.

2.3.4 PropertyPermission

The apparent intention of the security policy is that MIDlet Suites bound to the Unidentified Third Party protection domain are granted an PropertyPermission with an action of read for any system property except those with a prefix of

    microedition.deviceid.

or

    microedition.subscriberid.

but see Issues.

2.3.5 RuntimePermission

The RuntimePermission is ‘Not Permitted’.

3. Issues

3.1 EventPermission

The security policy lists the following EventPermissions

  1. EventPermission("*", "read")

  2. EventPermission("*", "register")

  3. EventPermission("*.*", "post")

Numbers 1 and 2 are ‘Allowed’ for both the Identified and Unidentified Third Party protection domains.

Number 3 is ‘Allowed’ for the Identified Third Party protection domain and ‘Not Allowed’ for the Unidentified Third Party protection domain.

The form of the target name for Number 3

    *.*

is presumably intended not to match the names of system Events, thereby preventing MIDlets in MIDlet Suites bound to the Identified
Third Party protection domain from posting them.

Unfortunately the class documentation for EventPermission currently defines the target name as follows

The target name is the name of the event (“BATTERY_LEVEL”, “com.MyCompany.MyEvent”, etc). The naming convention follows the hierarchical property naming convention and are explained in the package description. An asterisk MAY appear at the end of the event name, following a “.”, or by itself, to signify a wildcard match. For example: “com.MyCompany.*” or “*” is valid, but “*MyCompany” or “a*b” is not valid.

so

    *.*

is not actually legal.

3.2 PropertyPermision

The security policy lists the following PropertyPermissions

  1. PropertyPermission("microedition.deviceid.*", "read")

  2. PropertyPermission("microedition.subscriberid.*", "read")

  3. PropertyPermission("microedition.locale", "read")

  4. PropertyPermission("microedition.profile", "read")

  5. PropertyPermission("microedition.platform", "read")

  6. PropertyPermission("microedition.*", "read")

Numbers 1 and 2 are described as not granted to MIDlet Suites bound to the Unidentified Third Party protection domain.

This however is somewhat moot given the presence of number 6.

Try running the following using a JSE distribution and you will see why.


    package scratch.propertypermission;

    import java.util.PropertyPermission;

    public final class PropertyPermissionTest
    {
        public static void main(String[] theArgs)
        {
            PropertyPermission pp = new PropertyPermission("microedition.*", "read");
		
            for (int i = 0; i < PROPERTY_NAMES.length; i++)
            {
                String property = PROPERTY_NAMES[i];
			
                if (pp.implies(new PropertyPermission(property, "read")))
                {
                    System.out.print("Can read ");
                }
                else
                {
                    System.out.print("Cannot read ");
                }
                System.out.println(property);
            }
        }

        private static final String[] PROPERTY_NAMES = 
        {
            "microedition.deviceid.uuid",
            "microedition.deviceid.imei",
            "microedition.deviceid.esn",
            "microedition.deviceid.meid",
            "microedition.deviceid.pesn",
            "microedition.subscriberid.uuid",
            "microedition.subscriberid.imsi",
            "microedition.subscriberid.msisdn",
            "microedition.subscriberid.iccid",
            "microedition.subscriberid.euimid",
            "microedition.locale",
            "microedition.profiles",
            "microedition.platform",
            "microedition.commports",
            "microedition.hostname"
        };
    }


Possibly this usage is intended as a notational shorthand, but if so it is a very misleading one.


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

July 24, 2009

What’s New In MIDP 3.0 ? Part 43: Multiply Signed MIDlet Suites

Filed under: Java, JME, MIDletSuite, MIDP, MIDP Security, MIDP3 — Tags: , , , , , — Simon Lewis @ 4:30 pm

A MIDlet Suite may be signed using multiple distinct private keys.

This makes it posssible both

  • for the same entity to sign a MIDlet Suite multiple times, and

  • for different entities to sign the same MIDlet Suite

The first case means it is possible for a MIDlet Suite develper to obtain signing certificates from different sources, for example, network operators, and then sign a MIDlet Suite using the private key associated with each issued signing certificate. This in turn makes it possible to use the same signed MIDlet Suite on different operator networks, rather than having to re-package the MIDlet Suite for each network.

The second case makes it possible for a MIDlet Suite developer to sign a MIDlet Suite once, or multiple times as above, and then submit it to a third-party responsible for auditing or verifying its behaviour who can then sign it themselves.

The MIDlet-Jar-RSA-SHA1-<n> Attribute

A signature of a MIDlet Suite is specified using the

    MIDlet-Jar-RSA-SHA1-<n>

attribute.

The value of the attribute should be the Base-64 encoded signature of the MIDlet Suite JAR.

The canonical rules for ordinal based attributes apply. The first ordinal must be one (1). Any attribute after the first gap in the sequence is ignored.

For each signature there should be an associated certificate chain specified using one or more

    MIDlet-Certificate-<n>-<m>

attributes with the value of n in the certificate chain attributes corresponding to the value of n in the signature attribute.

The number of certificate chains must equal the number of signatures or the installation of the MIDlet Suite will fail.

Multiply Signing MIDP 2.x MIDlet Suites

Existing MIDP 2.x MIDlet Suites can also be multiply signed. If the

    Microedition-Profile

attribute specifies either

  • MIDP-2.0, or

  • MIDP-2.1

then MIDlet-Jar-RSA-SHA1-<n> attributes take precedence over the MIDlet-Jar-RSA-SHA1 attribute. If only the latter attribute is present then it it processed using the legacy MIDP 2.x authentication and verification algorithm.


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

What’s New In MIDP 3.0 ? Part 42: MIDlet Suite Attribute Miscellany

Filed under: Java, JME, MIDletSuite, MIDletSuite Attributes, MIDP, MIDP3 — Tags: , , , — Simon Lewis @ 11:52 am

1. MIDlet-Minimum-Canvas-Size And MIDlet-Maximum-Canvas-Size

The minimum size, in pixels, of a full-screen Canvas that the MIDlet(s) in a MIDlet Suite are intended to support can be specified at installation time using the

    MIDlet-Minimum-Canvas-Size

attribute.

The maximum size, in pixels, of a full-screen Canvas that the MIDlet(s) in a MIDlet Suite are intended to support can be specified at installation time using the

    MIDlet-Maximum-Canvas-Size

attribute.

Installation of the MIDlet Suite will fail if the specified constraints are not met by the primary Display of the device.

If both attributes are specified then it is an error if the minimum size is not less than or equal to the maximum size and installation of the MIDlet Suite will fail.

Note

  • The documentation for these attributes does not specify their format, nor can I find a definition of it anywhere else in the documentation.
    However, the early draft review did contain an example of a JAD containing the following

    MIDlet-Minimum-Canvas-Size: 120, 120

    so possibly that is the intended format ?

2. MIDlet-Required-IP-Version

The IP version required by a MIDlet Suite can be specified by using the

    MIDlet-Required-IP-Version

attribute.

The value of the attribute must be one of

  • ipv4
  • ipv6
  • any

If the required version is not supported by the device then installation of the MIDlet Suite will fail.

3. MIDlet-Profile-Request

The

    MIDlet-Profile-Request

attribute is used to specify that the MIDlet Suite JAD download request must be accompanied by the UAProf headers necessary to detemine the capabilities of the device.

The specification requires that this is done for all JAD downloads, however, it is possible that the JAD was downloaded in some another manner and then passed to the MIDP 3.0 implementation. In these circumstances if the MIDlet-Profile-Request attribute is present and has the value true then the JAD download must be repeated with the download request being accompanied by the necessary UAProf headers.

4. MIDlet-Upate-URL

The

    MIDlet-Update-URL

can be used to specify an RFC 3986 conformant absolute URL to be used for automatic updates of the MIDlet Suite

Note

  • It is not clear from the specification what the automatic update of a MIDlet Suite actually involves.

    The attribute documentation says

    If the value contains a valid URL, the automatic update of the MIDlet suite MUST be requested from this URL. Note that this overrides the priority rules used to decide which URL is used in updating. In this case other URLs MUST NOT be used, and other rules related to the update MUST remain in effect.

    If the URL is empty, user MUST NOT be able to activate the automatic update feature of the AMS.

    Searching the Provisioning section of the specification turns up this

    If the provisioned MIDlet suite has the MIDlet-Update-URL attribute in the JAD file or the JAR manifest, the implementation MUST use it to configure the automatic update feature. The value of this attribute MUST either be empty or contain a valid URL. For details, see the description of the MIDlet-Update-URL attribute in Application Attributes.

    which simply refers to the attribute documentation quoted above, and that is the only occurence of the word automatic anywhere in the Provisioning section.


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

What’s New In MIDP 3.0 ? Part 41: Preventing Users From Upgrading Or Uninstalling MIDlet Suites

Filed under: Java, JME, MIDletSuite, MIDP, MIDP3 — Tags: , , , , — Simon Lewis @ 9:51 am

A user can be prevented from upgrading and/or uninstalling a MIDlet Suite by using the

    MIDlet-UserDenied

attribute.

The value of the attribute is a comma separated list of the actions the user is not allowed to perform.

The actions are

  • delete
  • update

meaning that the user cannot

  • uninstall
  • upgrade

the MIDlet Suite respectively.

To use this attribute the MIDlet Suite must be granted the ActionsDeniedPermission. The default MIDP 3.0 security policy does not grant this permission to MIDlet Suites bound to the Identified Third Party, or Unidentifed Third Party protection domains. By default therefore this feature is only available to manufacturers and operators.


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

What’s New In MIDP 3.0 ? Part 40: MIDlet Suite Scalable Icons

Filed under: Java, JME, MIDletSuite, MIDletSuite Attributes, MIDP, MIDP3 — Tags: , , , , — Simon Lewis @ 9:42 am

Like MIDlets a MIDlet Suite can have a scalable icon.

This can be specified at installation time using the

    MIDlet-Scalable-Icon

attribute.

The value of the attribute should be the path of a file within the MIDlet Suite JAR which contains scalable image data in the SVG Tiny 1.1 format.

A locale specific version of the MIDlet Suite icon can be specified using the

    MIDlet-Scalable-Icon-<locale>

attribute.

See Localizable Attributes for the semantics of localized attributes.


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

What’s New In MIDP 3.0 ? Part 39: Localizable MIDlet Suite Attributes

Filed under: Java, JME, MIDletSuite, MIDletSuite Attributes, MIDP, MIDP3 — Tags: , , , , — Simon Lewis @ 9:18 am

See Localizable Attributes for a description of the semantics of localizable attributes.

Attribute Locale Specific Attribute
MIDlet-Name MIDlet-Name-<locale>
MIDlet-Icon MIDlet-Icon-<locale>
MIDlet-Description MIDlet-Description-<locale>
MIDlet-Delete-Confirm MIDlet-Delete-Confirm-<locale>

Note

  • There is one new MIDlet Suite Attribute MIDlet-Scalable-Icon which is also localizable. This is described separately.


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

What’s New In MIDP 3.0 ? Part 38: Tied Operator MIDlets

Filed under: Java, JME, MIDlets, MIDP, MIDP3 — Tags: , , , , — Simon Lewis @ 8:51 am

At installation time a MIDlet Suite can be tied to a specific country and network using the

    MIDlet-Operator-Allowed

attribute.

The value must be a blank separated list of MCC/MNC pairs, where an MCC/MNC pair is a three digit MCC separated from a two or three digit MNC by a hyphen.

For example,

        234-15

Following a successful installation, MIDlets in the MIDlet Suite will not be excutable unless the current MCC and MNC correspond to one of the specified pairs.

This attribute only applies to MIDlet Suites bound to the Operator protection domain.


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

July 23, 2009

What’s New In MIDP 3.0 ? Part 37: ScreenSaver MIDlets

Filed under: Java, JME, MIDlets, MIDP, MIDP3 — Tags: , , , , — Simon Lewis @ 8:03 pm

The ScreenSaver MIDlet Model

  • A ScreenSaver MIDlet is any MIDlet which has been declared with a type of screensaver at installation time.

  • A ScreenSaver MIDlet may be selected by the user as the current screen saver.

  • A ScreenSaver MIDlet is responsible for determining when it should be acting as the screen saver.

    • To do this it must determine

      1. whether it is the currently selected screen saver

      2. when the device enters and leaves screensaver mode

  • A MIDlet can determine whether it is the currently selected screen saver by calling it’s isSelectedScreenSaver() method.

  • A MIDlet can determine when the device enters and leaves screensaver mode by listening for EventData.SCREENSAVER_MODE events.

  • A ScreenSaver MIDlet will be started automatically if it is is the currently selected screen saver and it is not running when the device enters screen saver mode.

Notes

  1. It is not clear what behaviour is expected of a ScreenSaver MIDlet if it has access to multiple Displays.

  2. Although there is apparently a potential race-condition if a ScreenSaver MIDlet is started automatically when the device enters screen saver mode, the semantics of the EventManager.addEventListener() methods should help avoid this. As the EventManager class documentation says

    For system events, as soon as a listener is added or an application is registered to be launched the current value is checked. If the current value is matched, the listener MUST be immediately notified or the application is launched.

    If the ScreenSaver MIDlet uses the EventManager.addEventListener(String, EventDataListener, boolean) variant of the method to register for the EventData.SCREENSAVER_MODE eventthen it will be notified of current state of the device’s screen saver mode

  3. Listening for the EventData.SCREENSAVER_MODE requires an EventPermission for that event with an action of read. A MIDlet Suite containing a Screensaver MIDlet needs to ensure it requests that permission.

  4. In the javax.microedition.midlet package documentation, when describing the sequence of events that the screen saver MIDlet MAY expect it says

    The MIDlet’s Display capabilities are changed to indicate no further user input events will be delivered to the screen saver MIDlet.

    It is not clear whether capabilities in this context means the values returned by the Display.getCapabilities() method. The reference to Display and the use of the word indicate seem to imply that it does, but if so then it contradicts the Display documentation where it says

    A given Display’s capabilities are static; that is, they do not change over time or in response to the state of the device.

    If not then this should be made clear.


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

What’s New In MIDP 3.0 ? Part 36: IdleScreen MIDlets

Filed under: Java, JME, MIDlets, MIDP, MIDP3 — Tags: , , , , , — Simon Lewis @ 11:52 am

The IdleScreen MIDlet Model

  • An Idlescreen MIDlet is any MIDlet which has been declared with a type of idlescreen at installation time.

  • A user may choose to add an Idlescreen MIDlet to the idle screen of a Display.

    • If the chosen MIDlet is not running when added then it will be started automatically.

  • An Idlescreen MIDlet can access the idle screen of a Display using an IdleItem.

  • An Idlescreen MIDlet which has been added to the idle screen of a Display but which does not access it using an IdleItem may be removed from the idle screen and terminated

  • A MIDlet which is not declared to be an Idlescreen MIDlet cannot access the idle screen of any of its Displays

Notes

  1. Should it have access to the idle screens of multiple Displays it is not clear how an Idlescreen MIDlet is supposed to determine which of them,
    if any, it is supposed to be responsible for displaying on.

  2. The javax.microedition.lcdui documentation says

    If a MIDlet that has not announced itself as an idle screen MIDlet with the JAD or JAR Manifest attribute
    tries to add content to the idle screen, the system MUST ignore this request.

    Presumably this means that any calls to Display.setIdleItem(IdleItem) will simply have no effect.


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

Older Posts »

Blog at WordPress.com.

%d bloggers like this: