Printer-friendly versionSend to friend

There are a set of OEM and standard MIDP functions on Motorola's MIDP 2.0 phones that are covered under the Security Domains architecture defined by the MIDP 2.0 specification. The Security Domains system was defined in the specification to prevent the abuse of certain Java ME functions that have ligitimate uses but that may have privacy or cost implications for end users. The Security Domain Policies control under what circumstances a MIDlet may use those functions.

The implementation of Security Domains on Motorola iDEN MIDP 2.0 phones includes both sensitive MIDP 2.0 functions as well as some of the OEM classes available on the handset.

Under the security domains framework, functions or sets of functions within an application programming interface (API) can be protected and defined as being available only to properly authorized applications. This security framework consists of three parts:

• Function groups, which are logical arrangements of functions that have similar end-user effects;
• the MIDlet’s security domain, which specifies the level of trust that Nextel or Motorola have granted to the MIDlet;
• the permission setting of a MIDlet as defined in its JAD file or JAM configuration, which, based on its security domain, grants the MIDlet permission to perform actions within a function group.

The following function groups have been defined in the Falcon platform, and incorporate all functions that perform the actions listed:

Phone Call Receive

Any function that results in a MIDlet handling a voice call

Net Access

Any function that results in an active network data connection

Messaging: Any function that allows sending or receiving text messages on the handset (note that mobile-originated SMS is not currently supported by Nextel)

Application Auto Invocation

Any function that allows a MIDlet suite to be invoked automatically

Local Connectivity

Any function that activates a local port such as the serial port

Multimedia recording

Any function that gives a MIDlet suite the ability to capture still images, or to record video or audio clips

Read User Data Access

Any function that gives a MIDlet suite the ability to read a user's phone book, date book, or any other user information

Write User Data Access

Any function that gives a MIDlet suite the ability to modify a user's phone book, date book, or any other user information

Location

Any function that gives a MIDlet suite the ability to get device’s location. This function group is subject to being overridden by the GPS Privacy Settings on the handset (see Answer #195)

System Information Access

any function that gives a MIDlet suite the ability to get device’s system information such as the IMEI

System Control

Any function that gives a MIDlet suite the ability to control the settings of the device, such as audio volume

MIDlets are granted or denied access to functions based on their security domain:

Manufacturer Domain

includes any MIDlets developed by or on behalf of Motorola

Operator Domain

includes any MIDlets developed by or on behalf of Nextel

Trusted Third Party Domain

includes MIDlets from third parties who have received Motorola’s and Nextel’s explicit trust, expressed in the form of a digital signature in the MIDlet's JAD file, by presenting their MIDlet for a process known as code signing

Untrusted Domain

any MIDlet from any third party, that does not carry a code signature

Based on its security domain, a MIDlet can be granted one of various permission settings to perform the actions in a function group:

Allowed

provides explicit permission to a specific function group based solely on the security domain of the MIDlet. MIDlets with Allowed permission do not require any user interaction for that function to execute

Blanket

provides permission to a MIDlet for a specific function group until it is removed from the handset or until the user changes the permission. Applications granted Blanket permission will cause the system to prompt the user at least once before the first invocation of the protected function. If the permission is granted, the user is not prompted again for the life of the MIDlet

Session

provides permission to a MIDlet for a function group until execution of the MIDlet ends. Users are prompted only once per session, but must be prompted at every session before the protected function is called

Oneshot

allows a MIDlet to use a protected function but prompts the user every time the function is invoked

Deny

prevents access to a function group based on a MIDlet being associated with a security domain that blocks that function

A matrix of the various combinations of security domains, function groups and available permission settings is below:

Function group Manufacturer Domain Operator Domain Trusted Third Party Domain Untrusted Domain

Phone Call Receive

Default A A A A Others B, S, O B, S, O B, S, O B, S, O Messaging Default A A O O Others B, S, O B, S, O S S Application Auto Invocation Default A A S S Others B, S, O B, S, O B, O B, O Multimedia recording Default A A S O Others B, S, O B, S, O B S Read User Data Access Default A A O O Others B, S, O B, S, O S, B N/A Write User Data Access Default A A O O Others B, S, O B, S, O S, B N/A System Information Access Default A A S O Others B, S, O B, S, O O, B N/A System Control Default A A O O Others B, S, O B, S, O N/A N/A GPS Location Default A A B B Others B, S, O B, S, O S, O S, O Network Access Default A A A A Others B, S, O B, S, O B, S, O B, S, O Local Connectivity Default A A A A Others B, S, O B, S, O B, S, O B, S, O

KEY:
A – Always Allowed, never prompt	S – Session
B – Blanket permission, prompt only once	O – Oneshot permission, prompt every time

Signing during testing

The Motorola iDEN SDK for J2ME (MIDP 2.0) includes a code signing tool that allows a MIDlet to run under Trusted Third Party status for 48 hours on up to one handset, which is useful during testing. To use it, do the following:

• Using the Manifest/JAD Editor in the SDK, go to the "Security" tab and add the APIs that you are using that are covered under the Security Domains policies listed above. (You can also add these entries manually into your JAD file, but keep in mind that if the MIDlet-Permissions property is not properly formatted with commas and spaces in the right place, the JAD signing process will fail).
• Once you have edited your JAD file, click on "JAD Sign" on the toolbar and select either TTP for "Trusted Third Party" or OPA for "Operator" -- this corresponds to the columns with the same name in the matrix above.
• Enter the IMEI of the phone on which you will be running the signed MIDlet. The signature generated by the JAD sign tool is tied to the IMEI, and the signed MIDlet will only run on the phone with that IMEI.
• Click on sign. If all goes well, you will receive a "sign successfully" message. This will grant you the ability to load the application on that one phone and run under the signed domain for 48 hours. Once the 48 hours expire, you will need to re-sign the application using the JAD sign tool.

If you have any problems with the JAD Sign tool, it may be related to the configuration of your Java 2 Standard Edition (J2SE) environment:

• If you receive a "failed to sign" error when using the JAD Sign tool in the Motorola iDEN SDK, the most likely cause of this is that you do not have the path to keytool.exe (part of the Java 2 Standard Edition distribution) in your PATH environment variable. Locate keytool.exe (usually in the bin\ directory of wherever your JDK is installed) and place the path to that directory in your system's PATH variable. You may also be trying to sign a JAD file that is locked. Check the file properties and make sure that the JAD file can be edited.
• If you are successful in signing, but receive an "Authentication Error" when you load the MIDlet onto your device, It may be due to having entered an incorrect IMEI in the signing screen (make sure you obtain the one from the device by typing
  

  # * MENU Right Arrow

  from the main screen of the device).

• If your JAR file contains class files that would never actually be invoked, you may see an "authentication error". This might happen if you created a class that you decided not to use, and ended up removing references to it in your midlet's main() method or subsequent code. Remove all the .class files in your project directory and rebuild your application.

Signing for production use or for proofs of concept

Keep in mind that code signing is not required to use most of these functions and to obtain valid results from them: trusted status allows an application to perform these functions without having to obtain explicit permission from the user. The only two functionalities that absolutely require a digital signature (in OPA mode) are com.moto.iden.CustomerCare.getMyInfo, com.moto.iden.CustomerCare.getClientInfo, and platformRequest("http://*")). In the vast majority of cases, the default permissions are the most desirable outcome, since they notify the user of an operation that he or she should usually know about. In some situations (such as with enterprise applications), having the user notified of these activities may not be desirable, in which case you would probably benefit from having a signature that allows you to set a permission to "Always" by default.

When your application is ready for controlled or production deployment, and if it needs TTP or OPA signing to operate properly, you will need to request a code signature from the Nextel market where you are trying to run the application. If you have an established contact with a Nextel Data Sales representative in your market or with a representative from the marketing organization in your country, you should approach that person first. If you would like to request a code signature for your application and don't have an established contact with an NII (Nextel International) market, please contact us and we'll guide you through the process. Note: If you are looking to get your application signed for use in the United States on the Sprint Nextel network, please contact the Sprint Application Developer Program for guidance..

Applications signed by Motorola and Nextel under TTP or OPA domains do not have the 48-hour and one-IMEI restrictions. Every time you recompile your application or make a change that modifies the JAR file, you will need to obtain a new signature.