Skip Headers
Oracle® Java Micro Edition Software Development Kit Developer's Guide
Release 3.2 for Windows
  Go To Table Of Contents
Go To Index


13 Security and MIDlet Signing

The SDK provides tools to sign MIDlet suites, manage keys, and manage root certificates.

MIDP 2.0 (JSR 118) includes a comprehensive security model based on protection domains. MIDlet suites are installed into a protection domain that determines access to protected functions. The MIDP 2.0 specification also includes a recommended practice for using public key cryptography to verify and authenticate MIDlet suites.

The general process to create a cryptographically signed MIDlet suite is as follows:

  1. The MIDlet author, probably a software company, buys a signing key pair from a certificate authority (the CA).

  2. The author signs the MIDlet suite with the signing key pair and distributes their certificate with the MIDlet suite.

  3. When the MIDlet suite is installed on the emulator or on a device, the implementation verifies the author's certificate using its own copy of the CA's root certificate. Then it uses the author's certificate to verify the signature on the MIDlet suite.

  4. After verification, the device or emulator installs the MIDlet suite into the security domain that is associated with the CA's root certificate.

For definitive information, consult the MIDP 2.0 specification. For an overview of MIDlet signing using the Oracle Java ME SDK, read the article Understanding MIDP 2.0's Security Architecture, which is available at

If you need more background on public key cryptography, try the article MIDP Application Security 1: Design Concerns and Cryptography, which is available at See the following topics:

13.1 Security Domains

The SDK supports the following security domains:

minimum. All permissions are denied to MIDlets in this domain.

maximum. All permissions are granted to MIDlets in this domain. Maximum is the default setting.

unidentified_third_party. Provides a high level of security for applications whose origins and authenticity cannot be determined. The user is prompted frequently when the application attempts a sensitive operation.

identified_third_party. Intended for MIDlets whose origins were determined using cryptographic certificates. Permissions are not granted automatically, but the user is prompted less often than for the unidentified_third_party domain.

operator. All permissions are denied to MIDlets in this domain.

manufacturer. Intended for MIDlet suites whose credentials originate from the manufacturer's root certificate.

13.2 Setting Security Domains

In the SDK, when you use Run Project via OTA your packaged MIDlet suite is installed directly into the emulator where it is placed in a security domain. The emulator uses public key cryptography to determine the appropriate security domain.

If your project is a MIDlet suite, the entire suite is signed (the individual MIDlets contained within are not).

13.2.1 Specify the Security Domain for an Emulator

  1. In the Device Selection window, right-click on the device and select Properties.

  2. Find the Security Domain setting and make a selection from the context menu.

    The SDK knows the runtimes the device can support and supplies only possible domains. The default setting for the sample projects is Maximum. See Section 6.4, "Setting Device Properties".

13.2.2 Specify the Security Domain for a Project

  1. Right-click on a project and select Properties.

  2. In the Category area, select Running (the green triangle).

  3. Select Regular Execution and check the Security domain box.

    In this context regular execution means you are running in the emulator, as opposed to running OTA.

  4. Select the domain from the drop-down menu.

13.3 Signing a Project

Devices use signing information to check an application's source and validity before allowing it to access protected APIs. For test purposes, you can create a signing key pair to sign an application. The keys are as follows:

You can create a key pair with the Keystores Manager as described in Section 13.4, "Managing Keystores and Key Pairs".

13.3.1 Sign a CLDC Project With a Key Pair

  1. Right-click on a project and select Properties.

  2. From the Build hierarchy, select Signing.

  3. Check the Sign Distribution checkbox.

  4. Choose a keystore from the Keystores drop-down menu, or click Open Keystores Manager to create a new keystore.

    The Certificate Details area displays the Alias, Subject, Issuer, and validity dates for the selected keystore.

  5. Choose a key pair alias from the drop-down menu.

    A keystore might be accessed by several key pairs, each with a different alias. If you prefer to use a unique key pair, select Open Keystores Manager and create a new key pair. See Section, "Create a Keystore".

  6. Click OK.

See Section 5.4.5, "Obfuscating".

13.3.2 Sign a CDC Project

To sign a CDC project use the JDK jarsigner command from the command line. For example:

jarsigner.exe -keystore keystore.ks -storepass keystorepwd MyCdcApp.jar dummyCA

13.4 Managing Keystores and Key Pairs

For test purposes, you can create a signing key pair to sign a MIDlet. The Keystores Manager administers this task, as described in the remainder of this topic, the key pair consists of two keys:

To deploy on a device, you must obtain a signing key pair from a certificate authority recognized by the device. You can also import keys from an existing Java SE platform keystore.

The following topics describe the user interface:

You can also use the command line tools described in Section 14.6, "Command Line Security Features".

13.4.1 Working With Keystores and Key Pairs

The Keystores Manager handles creating and using keystores. The keystores known to the Keystores Manager are listed when you sign a project, as described in Section 5.4.6, "Signing".

Keystores contain key pairs, which you can also manage from this dialog. You must select a keystore to access the key pair tools. Create a Keystore

  1. Select Tools > Keystores.

    The Keystores Manager opens.

  2. Click Add Keystore...

    The Add Keystores window opens.

  3. Choose Create a New Keystore.

  4. Supply a name, location, and password.

    userhome\My Documents

  5. Click OK.

    The new keystore appears in the Keystores list. Add an Existing Keystore

  1. Select Tools > Keystores.

    The Keystores Manager opens.

  2. Click Add Keystore.

    The Add Keystores window opens.

  3. Choose Add Existing Keystore.

  4. Browse to the location of the keystore and select the keystore file. The default location for user-defined keystores is:

    userhome\My Documents

  5. Select a keystore and Click Open, then click OK.

    The existing keystore appears in the Keystores list. You might have to unlock this keystore, and each key pair within it. Create a New Key Pair

  1. Select Tools > Keystores.

    The Keystores Manager opens.

  2. Select a Keystore in the Keystores area on the left. If you prefer a different keystore, you can create one as described in Section, "Create a Keystore".

    Note, you cannot Add a key to the Built-in Keystore, but you can export a key from it.

  3. Click the New... button.

  4. Fill in the Create Key Pair dialog:

    You must provide an alias to refer to this key pair.

    The six Certificate Details fields are provisionally optional. You must complete at least one field.

    Key Pair Alias. The name used to refer to this key pair.

    Common Name. Common name of a person, such as "Jane Smith"

    Organization Unit. Department or division name, such as "Development"

    Organization Name. Large organization name, such as "Sun Microsystems Inc."

    Locality Name. Locality (city) name, such as "Santa Clara"

    State Name. State or province name, such as "California"

    Country. Two-letter country code, such as "US"

    You must provide a password at least six characters long.

  5. Click OK.

    The new key is displayed in the Keys area under its alias. You can now select this keypair when you sign a project. See Section 13.3, "Signing a Project". Remove a Key Pair

  1. Select Tools > Keystores.

  2. In the Keys area, click a Key Pair.

  3. Select Delete. You are asked if you are sure. Click Yes if you are and the delete proceeds. Import an Existing Key Pair

If you have keys in a Java SE platform keystore that you would like to use for MIDlet signing, you can import the signing keys to the Java ME SDK.

  1. Select Tools > Keystores.

  2. Click Add Keystore...

    The Add Keystore window opens.

  3. Click Add Existing Keystore.

  4. Browse to the keystore location.

  5. Click OK.

13.5 Managing Root Certificates

The Oracle Java ME SDK command line tools described in Section 14.6.3, "Manage Certificates (MEKeyTool)" manage the emulator's list of root certificates.

Real devices have similar lists of root certificates, although you typically cannot modify them. When you deploy your application on a real device, you must use signing keys issued by a certificate authority whose root certificate is present on the device. This makes it possible for the device to verify your application.

Each emulator instance has its own _main.ks file located in its appdb directory. For example: userhome\javame-sdk\3.2\work\devicename\appdb.

You can use the -import option to import certificates from these keystores as described in Section 14.6.3, "Manage Certificates (MEKeyTool)".