| Oracle® Java Micro Edition Software Development Kit Developer's Guide Release 3.0.5 for Windows E24265-04 |
|
 Previous |
 Next |
| Oracle® Java Micro Edition Software Development Kit Developer's Guide Release 3.0.5 for Windows E24265-04 |
|
Previous |
Next |
The Java ME SDK supports the security policies and domains defined by both JSR 185 (Java Technology for the Wireless Industry or JTWI) and JSR 248 (Mobile Service Architecture or MSA). The SDK provides tools to sign MIDlet suites, manage keys, and manage root certificates. The security domains are further described in Section 12.1, "Security Domains".
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 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 five security domains for MSA:
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.
manufacturer. Intended for MIDlet suites whose credentials originate from the manufacturer's root certificate.
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.
The SDK includes four JTWI security domains:
untrusted. 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.
trusted. All permissions are granted to MIDlets in this domain.
minimum. All permissions are denied to MIDlets in this domain.
maximum. All permissions are granted to MIDlets in this domain (equivalent to trusted.) Maximum is the default value.
In the SDK, when you use Run 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 suite is not signed, it is placed in the default security domain.
If the MIDlet 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 12.3, "Signing a Project".
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 for both MSA and JTWI is Maximum. See the topic "Setting Device Properties".See Section 6.3, "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 12.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 12.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 that can be used by anyone 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 13.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. Click OK.
C:\Documents and Settings\user\My Documents
Click OK.
The new keystore appears in the Keystores list.
Select Tools > Keystores.
The Keystores Manager opens.
Select a Keystore in the Keystores area on the left.
If you prefer a different keystore, select Add Keystore to create a new keystore or add an existing keystore.
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"
The password is optional. If you do provide a password, it must have at least six characters.
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 12.3, "Signing a Project".
The Java ME SDK command line tools described in Section 13.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.0.5\work\emulator-instance-id\appdb.
The micro keystore, _main.ks resides in the following directory:
installdir\runtimes\cldc-hi\appdb\
The default keystore keystore.ks resides in installdir\runtimes\cldc-hi\lib.
You can use the -import option to import certificates from these keystores as described in Section 13.6.3, "Manage Certificates (MEKeyTool)".
|
 Copyright © 2009, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|