Oracle® Java Micro Edition Software Development Kit Developer's Guide Release 3.2 for Windows E24265-04 |
|
Previous |
Next |
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:
The MIDlet author, probably a software company, buys a signing key pair from a certificate authority (the CA).
The author signs the MIDlet suite with the signing key pair and distributes their certificate with the MIDlet suite.
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.
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 http://developers.sun.com/techtopics/mobility/midp/articles/permissions/
.
If you need more background on public key cryptography, try the article MIDP Application Security 1: Design Concerns and Cryptography, which is available at http://developers.sun.com/techtopics/mobility/midp/articles/security1/
. See the following topics:
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.
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 the MIDlet or MIDlet suite is not signed, it is placed in the default security domain.
If the MIDlet or MIDlet suite is signed, it is placed in the protection domain that is associated with the root certificate of the signing key's certificate chain. See Section 13.3, "Signing a Project".
If your project is a MIDlet suite, the entire suite is signed (the individual MIDlets contained within are not).
In the Device Selection window, right-click on the device and select Properties.
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".
Right-click on a project and select Properties.
In the Category area, select Running (the green triangle).
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.
Select the domain from the drop-down menu.
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:
A private key that is used to create a digital signature, or certificate.
A public key that anyone can use to verify the authenticity of the digital signature.
You can create a key pair with the Keystores Manager as described in Section 13.4, "Managing Keystores and Key Pairs".
Right-click on a project and select Properties.
From the Build hierarchy, select Signing.
Check the Sign Distribution checkbox.
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.
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 13.4.1.1, "Create a Keystore".
Click OK.
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
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:
A private key that is used to create a digital signature, or certificate.
A public key anyone can use to verify the authenticity of the signature.
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".
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.
Select Tools > Keystores.
The Keystores Manager opens.
Click Add Keystore.
The Add Keystores window opens.
Choose Add Existing Keystore.
Browse to the location of the keystore and select the keystore file. The default location for user-defined keystores is:
userhome\My Documents
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.
Select Tools > Keystores.
The Keystores Manager opens.
Select a Keystore in the Keystores area on the left. If you prefer a different keystore, you can create one as described in Section 13.4.1.1, "Create a Keystore".
Note, you cannot Add a key to the Built-in Keystore, but you can export a key from it.
Click the New... button.
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.
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".
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)".