Home > Articles > Programming > Java

This chapter is from the book

J2ME Security Architecture

The Java 2 Micro Edition (J2ME) is designed to deliver the benefits of Java technology on microdevices and embedded systems with limited constraints on their resources, such as memory size, display size, processing power, network bandwidth, and battery life. The J2ME platform provides the runtime environment and API technologies to support a broad range of consumer electronics, embedded devices, and personal mobile devices such as cellular phones, personal digital assistants (PDAs), TV set-top boxes, telematic systems, electronic appliances, and so forth. J2ME offers a rich graphical user interface, storage, networking, security, and other capabilities that include browsing Web applications and running mobile gaming applications. J2ME is also designed to produce portable code and to establish portability of applications across device groups such as PDAs and smartphones. With its security and portability benefits, today J2ME is widely adopted as a core platform for building customized services on a variety of devices and for running mobile applications.

In general, J2ME is a slimmed-down version of J2SE. To enable J2ME applications to meet the device resource constraints and to run efficiently, many API components have been removed from the core Java platform. Figure 3-3 illustrates the J2ME platform architecture and its elements.

03fig03.gif

Figure 3-3 J2ME platform architecture and core elements

J2ME defines the notion of configurations and profiles to represent the characteristics of supported devices. These configurations and profiles are developed by the industry groups participating in the Java community process.

J2ME Configurations

A J2ME configuration defines Java runtime and API technologies that satisfy the needs of a broad range of devices. Configurations are defined based on the device limitations and the characteristics of memory, display, processing power, network connectivity, and so forth.

The current J2ME specification defines two types of configurations: Connected Device Configuration (CDC) and Connected Limited Device Configuration (CLDC).

CDC

CDC targets high-end consumer devices with TCP/IP network connectivity and higher bandwidth. It requires at least 2Mb memory available for the Java platform. It defines a full-featured JVM that includes all the functionality of a Java runtime environment residing on a standard desktop system. The low-level interfaces for calling native code (JNI), connecting to debuggers (JVMDI), and profiling code (JVMPI) are optional. Vendors may adopt them based on device requirements.

03fig04.gif

Figure 3-4 J2ME platform configuration and profiles

CDC provides a full-featured Java security model and associated mechanisms of a J2SE environment:

  • All code runs in a sandbox without exposing the user's system to risk. All classes are loaded with full byte-code verification and Java language features.
  • Signed classes verify the integrity and originating source of the Java classes when the JVM attempts to load it.
  • Security policy provides fine-grained access control over the resources using a user-defined set of permissions and policies.
  • Support for Java cryptography to secure programs, data, communication, and retrieval is provided.

In short, CDC offers all the security benefits leveraging a standard J2SE environment and gives architects and developers the flexibility to use different Java security API capabilities for building secure applications. J2ME runtime implementations built on the CDC may utilize the standard JVM bundled with the J2SE or the Compact Virtual Machine (CVM) depending on the size of the device for which the implementation is being developed.

CLDC

CLDC targets low-end consumer devices, with only 128–512 kilobytes of memory required for the Java platform and running applications. It features a subset of a standard JVM with limited API and supporting libraries.

When compared to the J2SE implementation, J2ME differs as follows:

  • Limited security model
  • New class verification mechanism
  • No user-defined class loaders
  • No support for thread groups or daemon threads
  • No support for weak references
  • Limited error handling
  • No finalization
  • No reflection support
  • New connection framework for networking

CLDC runs on top of Sun's K Virtual Machine (KVM), which is a JVM designed specifically for supporting resource-limited devices. KVM is the core component of the J2ME platform for CLDC devices. CLDC defines two levels of security: Low-level KVM security and application-level security.

Low-level KVM security: An application running in the KVM must not be able to harm the device in any way. Such security is guaranteed by a pre-verification process that rejects invalid class files and ensures that a class does not contain any references to invalid memory locations. The preverify tool is responsible for the verification process, and it inserts some special attributes into the Java class file. After pre-verification, the KVM does an in-device verification process, which ensures that the class is pre-verified. Figure 3-5 illustrates a CLDC verification process.

03fig05.gif

Figure 3-5 Pre-verification process–KVM low-level security

Application-level security: The KVM defines a sandbox model that is quite different from the J2SE sandbox model. The sandbox requires that all Java classes are verified and guaranteed to be valid Java applications. It limits all but a predefined set of APIs from becoming available to the application as required by the CLDC specifications and supporting profiles. The downloading and management of applications take place at the native code level, and application programmers cannot define their own classloader or override the classloader or system classes and associated packages of the KVM. Application programmers also cannot download or add any native libraries that contain code and functionality that are not part of the CLDC supported libraries.

J2ME Profiles

J2ME profiles define a broader set of Java API technologies that are suited to a specific device class or a targeted class of devices. Profiles are built on top of J2ME configurations and define API libraries that enable specific types of applications that are suitable for the target devices. Each J2ME configuration supports one or more J2ME profiles. For the smallest of devices, the Mobile Information Device Profile (MIDP) is one such profile that is built on top of the CLDC configuration. The other class of devices based on CDC configuration use the Foundation Profile. The Foundation profile and its API libraries are based on J2SE 1.3.

Understanding MIDP and MIDlets

MIDP is designed for the family of limited computing devices that have wireless network connectivity and mechanisms for user input and display. The MIDP combined with the CLDC provides the execution environment and application functionality, which includes the user interface, application management, network connectivity, local data storage, and application life-cycle management. The CLDC and MIDP are packaged as a standardized J2ME runtime environment along with the API libraries and are deployed on the native operating system of the device. The OEM-specific classes are provided by the device manufacturer.

A MIDlet is a J2ME application designed to run on a mobile device. In simple terms, a MIDlet is a Java applet, except that it runs on a mobile device rather than in a Web browser. The mobile device provides an Application Management utility that is responsible for installing, executing, and removing MIDlet suites. The Java 2 Micro Edition Wireless Toolkit (J2ME WTK) provides a MIDlet development environment for creating and testing MIDP applications. Aside from the basics of building and packaging MIDlet suites, it includes tools for setting MIDlet security permission attributes, cryptographically signing MIDlet suites, and working with MIDP protection domains. The J2ME toolkit download is available for free from http://java.sun.com/j2me.

A MIDlet suite consists of one or more MIDlets packaged together as a JAR file. A packaged MIDlet will generally consist of compiled and pre-verified Java classes and other files, including images and application-related data. In addition to those files, a manifest file (manifest.mf) is also stored as part of the JAR file. The manifest file stores the MIDlet name, version, and MIDlet vendor-specific attributes. When running the JAR utility, it is important to use the -m option along with the manifest file in the arguments. Example 3-31 shows a manifest file.

Example 3-31. MIDlet JAR–manifest file

MIDlet-1: SecMidlet, /icons/csp.png, com.csp.SecMidlet
MMIDlet-Description: Example Manifest file illustration
MIDlet-Name: Example Secure Midlet
MIDlet-Permissions:
MIDlet-Vendor: Coresecuritypatterns.com
MIDlet-Version: 2.0
MicroEdition-Configuration: CLDC-1.0
MicroEdition-Profile: MIDP-2.0

In addition to a JAR file, a Java Application Descriptor (JAD) file is also required to be available as part of the MIDlet suite to provide information about the MIDlet(s) bundled in the JAR file. The JAD file provides information to the mobile device's application manager about the contents of the JAR file and also provides a way to pass parameters required by the MIDlet(s). The application manager requires that the JAD file have an extension of .jad. Example 3-32 shows an example of a JAD file.

Example 3-32. JAD file

MIDlet-1: SecMidlet,/icons/csp.png, com.csp.SecureMidlet
MMIDlet-Description: Example Manifest file illustration
MIDlet-Jar-URL: SecureMidlet.jar
MIDlet-Name: Example Secure Midlet
MIDlet-Permissions:
MIDlet-Vendor: Coresecuritypatterns.com
MIDlet-Version: 2.0
MicroEdition-Configuration: CLDC-1.0
MicroEdition-Profile: MIDP-2.0
MIDlet-Jar-Size: 19250

Use the ktoolbar GUI tool provided with the J2ME WTK to load the JAD file and the JAR file containing the MIDlet suite from a local filesystem.

MIDlet Security

The MIDP 1.0 specification introduced the basic security feature that restricts all MIDlet suites to operate within a sandbox-based security model. This was primarily done to ensure that MIDlets prevent access to sensitive APIs and functions of devices, and to avoid any risks to the device resources.

The MIDP 2.0 introduced the notion of trusted MIDlets to provide a flexible and consistent security model with access-control mechanisms defined by a domain policy. The device enforces access control on a MIDlet suite as trusted MIDlets in accordance with the defined domain policy. A MIDlet suite is identified as untrusted when the origin and integrity of the MIDlet suite's JAR file cannot be verified and trusted by the device. The MIDP 2.0 also specifies how MIDlet suites can be cryptographically signed so that their authenticity and originating source can be validated.

Trusted MIDlets

The MIDP defines a security model for trusted MIDlets based on a notion referred to as Protection Domains. Each protection domain associates a MIDlet with a set of permissions and related interaction modes, which allows a MIDlet to access the domain based on the permissions granted. A protection domain contains allowed and user permissions.

  • The allowed permissions define a set of actions that should be allowed without any user interaction.
  • The user permissions define a set of permissions that require explicit user approval. The MIDlet is bound by the protection domain and will allow or deny access to functions after prompting the user and obtaining their permissions.

In the case of user permissions, a MIDlet needs permission at the first time of access and asks the user whether the permission should be granted or denied. The user permission is defined to grant allow or deny permissions to specific API functions with the following three interaction modes.

  • Blanket: The MIDlet is valid for every invocation until its permission is revoked by the user or the MIDlet is deleted from the device.
  • Session: The MIDlet is valid for every invocation of the MIDlet suite until it terminates. It prompts the user for every initiated session on or before its first invocation.
  • Oneshot: The MIDlet is valid for a single invocation of a restricted method and prompts the user on each such invocation.

All user permission has a default interaction mode with an optional set of available interaction modes. These interaction modes are determined by the security policy. A policy consists of the definitions of domains and aliases. Each domain consists of the definition of granted permissions and user permissions. Aliases permit groups of named permissions to be reused in more than one domain and help keep the policy compact. Aliases may only be defined and used within a single policy file.

A domain is defined with a domain identifier and a sequence of permissions. The domain identifier is implementation-specific. Each permission line begins with allowing or denying user permissions and indicates the interaction modes, such as blanket, session, and oneshot for the specified list of permissions that follow. Example 3-33 shows a policy file.

Example 3-33. MIDlet policy file

domain: O="MIDlet Underwriters, Inc.", C=US
allow: javax.microedition.io.HttpConnection
oneshot(oneshot): javax.microedition.io.CommConnection

alias: client_connections
 javax.microedition.io.SocketConnection,
      javax.microedition.io.SecureConnection,
      javax.microedition.io.HttpConnection,
      javax.microedition.io.HttpsConnection

 domain: O=Acme Wireless, OU=Software Assurance
 allow: client_connections
 allow: javax.microedition.io.ServerSocketConnection,

              javax.microedition.io.UDPDatagramConnection
oneshot(oneshot): javax.microedition.io.CommConnection

domain: allnet
blanket(session): client_connections
oneshot: javax.microedition.io.CommConnection

To request permissions for executing a MIDlet suite, we will make use of attributes such as MIDlet-Permissions and MIDlet-Permissions-opt in a JAD descriptor file that signals a MIDlet suite's dependence on requiring certain permissions. These special JAD attributes represent the MIDlet suite and provide a device at installation time with access control information about which particular operations the MIDlet suite will be attempting. For example, suppose the MIDlet suite will attempt to make an HTTP connection and optionally make socket connections. The attributes in the JAD descriptor file would look like this:

 MIDlet-Permissions: javax.microedition.io.Connector.http
 MIDlet-Permissions-opt:
                     javax.microedition.io.Connector.socket

If a device attempts to install a MIDlet suite into a protection domain that doesn't allow the required permissions specified in the MIDlet suite's JAD file, the installation fails automatically. Thus, the trusted MIDlet provides the mechanisms that protect the device from poorly or maliciously written Java code that can render a device inoperable.

Signed MIDlet Suite

Since MIDP 2.0, a MIDlet suite can be cryptographically signed and its authenticity and originating source can be validated as trusted. This is an enhanced security model for MIDP applications, which is handled via digital signatures and PKI support. As with any PKI authentication, it requires zero or more root CA certificates that are used to verify other certificates. Signing a MIDlet suite is quite similar to signing applets that involve a signer and public key certificates. The signer of the MIDlet is responsible for distributing and supporting the MIDlets. The signer needs to have a public key certificate that can be validated by one of the protection domain root certificates on the device. A signed MIDlet suite usually includes a certificate issued by a well-known certificate authority. It is important to note that signing a MIDlet suite isn't useful unless client devices can verify the signature.

From a developer standpoint, signing a MIDlet suite is the process of adding the signer certificates and the digital signature of the JAR file to a JAD file. Signing a MIDlet suite adds new attributes to the JAD file, represented using Base 64 encoded values.

MIDlet-Certificate: <Base64 encoded value of certificate>
MIDlet-Jar-RSA-SHA1: <Base64 encoded value of signatures>

The J2ME Wireless Toolkit enables a signer to either sign a MIDlet suite with an existing public and private key pair obtained from a certificate authority or with a new key pair that can be generated as a self-signed certificate for testing purposes only. Each key pair is associated with a certificate. Assigning a security domain to the certificate designates the level of trust that the certificate holder has to access protected APIs and the level of access to those APIs.

The JADTool is a command-line interface provided with the J2ME toolkit for signing MIDlet suites. The JADTool only uses certificates and keys from J2SE keystores, discussed earlier in this chapter. As we discussed previously, the J2SE bundle provides key management tools for managing keystores.

The JADTool utility is packaged in a JAR file. To run it from the command line interface, change your current directory to {j2metoolkit-dir}\bin, and execute the following command:

   java –jar JADTool.jar <command-options> <JAD file>

Example 3-34 would add the certificate of the key pair from the given J2SE keystore to the specified JAD file.

Example 3-34. Adding a certificate to a JAD file

     java –jar JADTool.jar -addcert -keystore <mykeystore>
         -storepass <storepassword> -alias <alias>
         -inputjad <input_jadfile>
         -outputjad <output_jadfile>

Example 3-35 adds the digital signature of the given JAR file to the specified JAD file.

Example 3-35. Adding a digital signature to a JAD file

     java –jar JADTool.jar -addjarsig -jarfile <jarfile>
       -keystore <mykeystore>  -storepass <storepassword>
       -alias <alias>
       -inputjad <input_jadfile>
       -outputjad <output_jadfile>

Example 3-36 displays a list of certificates in a given JAD file.

Example 3-36. Displaying list of certificates for a given JAD file

   java –jar JADTool.jar -showcert
                       -inputJAD <input_jadfile>

If you don't wish to use the JADTool command-line utility, the J2ME toolkit also provides a GUI-based utility (Ktoolbar) that enables you to complete the entire signing process without having to use the command-line options. Finally, you may also choose to use the Ktoolbar tool to publish and then directly install the MIDlet suite in the device using Over-The-Air (OTA) provisioning techniques commonly adopted in wireless service deployment. The OTA provisioning mechanisms allow deploying applications wirelessly, the same way they send and receive messages or browse the Internet.

The J2ME platform [J2ME] also provides mechanisms for using cryptographic algorithms and securing network communication using SSL/TLS protocols as well as ensuring source authentication, integrity, and confidentiality. This will be discussed in Chapter 4. "Java Extensible Security Architecture and APIs."

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020