Contents Previous Next Index

Chapter   7

Security

This chapter describes the security functionality of the MIDP Reference Implementation. It is implemented in the Java™ programming language, and should therefore run without changes on a new device.

The document Security for MIDP Applications, which is part of the MIDP 2.0 Specification, gives MIDP implementations freedom in implementing the security functionality. (The document is available from  
http://jcp.org/jsr/detail/118.jsp.) The MIDP Reference Implementation demonstrates just one way. You may decide, given the requirements of a collaborator such as a service provider or network operator, to use a different approach and replace this implementation.

This chapter contains the sections:

7.1 Overview

The MIDP 2.0 Specification, available at http://jcp.org/jsr/detail/118.jsp, defines a security model that requires MIDlets to have permission to use security-sensitive APIs. This is different from the MIDP 1.0 security model, which had all MIDlet suites operate in a sandbox that prevented access to sensitive APIs or functions of the device.

The highlights of the MIDP Reference Implementation’s implementation of the security policy are:

See Using MIDP for more information on the MIDP Reference Implementation security policy and tools.

7.2 Permissions

MIDlet-suite developers using the MIDP Reference Implementation use the JadTool utility to sign a MIDlet suite. (See Using MIDP for more information on the JadTool utility.) Signing a MIDlet suite involves adding certificates to the JAD file, creating the digital signature of the JAR file, and adding the digital signature to the JAD file. The JadTool utility is in the com.sun.midp.jadtool package, which is in the midpInstallDir\tools directory.

When a user attempts to install a MIDlet suite, the MIDP Reference Implementation must determine whether the MIDlet suite can be trusted. The com.sun.midp.midletsuite.Installer class makes this determination by looking for and verifying a digital signature of the JAR file and certificates supporting the signature. If the JAR file is signed, the MIDP Reference Implementation expects the signature to be based on X.509 Public Key Infrastructure so that it can verify the signer and trust the MIDlet suite. The functionality supporting the PKI-secured permissions on signed jar files is the same functionality used in HTTPS certificate authentication (This is the com.sun.midp.ssl package; its reference documentation is reproduced in Appendix C.)

If a signed MIDlet suite can be trusted, it is installed and assigned a domain. If a signed MIDlet suite cannot be trusted, then it is not installed. (Note that an unsigned MIDlet suite can be installed and, if installed on the command-line, manually assigned a domain, as described in the previous section. See Using MIDP for more information.)

The MIDP Reference Implementation associates permissions with domains by reading and parsing the midpInstallDir\appdb\_policy.txt file. This is done in the classes:

As a MIDlet suite runs, the MIDP Reference Implementation must be able to determine which permissions it has. Protected APIs get the name of the currently running MIDlet from the com.sun.midp.midlet.Scheduler class when a MIDlet calls them, and uses the com.sun.midp.security.SecurityToken class to see whether the MIDlet has permission to run the method. When you port the MIDP Reference Implementation, ensure that all paths through security-sensitive APIs perform permission checks.

At times, the user must explicitly give or deny a MIDlet suite permission to access a protected API. The classes that query the user for permission are:

In addition to granting MIDlet suites the permissions to which they are entitled (and keeping them from using protected APIs for which they do not have permission) the MIDP Reference Implementation must also enable internal classes to perform their duties, including calling security-sensitive APIs when necessary. The security tokens for the internal classes are provided by the com.sun.midp.security.ImplicitlyTrustedClass interface. The class com.sun.midp.Main, being the first class running in the virtual machine (VM), uses the ImplicitlyTrustedClass interface to create and issue SecurityToken objects to the internal classes that need them. When you port the MIDP Reference Implementation, you must ensure that these security tokens are not available to applications.

7.3 Key Storage

To change the way public keys are stored, replace the com.sun.midp.publickeystore package. The following classes define a simple serialization mechanism (that is, a simple form of the mechanism defined by the java.io.Serializable interface in the Java 2 Standard Edition (J2SE™) platform) for storing and retrieving the public keys in the keystore:

The com.sun.midp.publickeystore.PublicKeyInfo class contains the information serialized for a public key.

The com.sun.midp.publickeystore.PublicKeyStore class defines a read-only ME keystore. It uses the PublicKeyInfo and InputStorage, above.

The following classes extend PublicKeyStore to create a read/write ME keystore so that keys can be managed:

If you change the key storage classes, you might also need to change the utility, MEKeyTool, that manages the keystore. The classes that comprise the MEKeyTool utility are in the com.sun.midp.mekeytool package. The classes are MEKeyTool and its inner classes:

The com.sun.midp.mekeytool package is in the midpInstallDir\tools directory.

 

Contents Previous Next Index Porting MIDP
MIDP Reference Implementation, Version 2.0 FCS

 

Copyright © 2002 Sun Microsystems, Inc. All rights reserved.