3. Signing a MIDlet Suite
To sign a MIDlet suite, a
supplier must create a public-private key pair and sign the MIDlet JAR
file with the private key. The JAR file is signed using the RSA-SHA1
algorithm. The resulting signature is encoded in Base64 format and
inserted into the application descriptor as the following attribute:
MIDlet-Jar-RSA-SHA1: <base64 encoding of JAR signature>
The supplier must obtain a
suitable MIDlet suite code-signing certificate from an appropriate
source, for example, the developer program of a device manufacturer or
network operator, containing the identity of the supplier and the
supplier's public key. The certificate is incorporated into the MIDlet
suite's application descriptor (JAD) file.
In the case of a
certification path, we need to include all the necessary certificates
required to validate the JAR file. Furthermore, a MIDlet suite may
include several certification paths in the application descriptor file
(if, for example, the MIDlet suite supplier wishes to target several
device types, each with a different root certificate). In Figure 3,
we need to include certificates containing the public keys belonging to
CA 1, CA 2 and the Supplier. The root certification authority's
certificate (the root certificate) is available on the device. Using the
root certification authority's public key, we can validate CA 1's
public key. This is then used to validate CA 2's public key, which is
then used to validate the Supplier's public key. The Supplier's public
key is then used to verify the origin and integrity of the JAR file. The
MIDP specification defines an application descriptor attribute of the
following format:
MIDlet-Certificate-<n>-<m>: <base64 encoding of a certificate>
Here <n>
represents the certification path and has a value of 1 for the first
certification path, with each additional certification path adding 1 to
the previous value (i.e. 1, 2, 3,...). There may be several
certification paths, each leading to a different root CA. <m>
has a value of 1 for the certificate belonging to the signer of the JAR
file and a value 1 greater than the previous value for each
intermediate certificate in the certification path.
For the example shown in Figure 3, with just one certification path, the relevant descriptor attribute entries would have the following content:
MIDlet-Certificate-1-1: <base64 encoding of Supplier's certificate>
MIDlet-Certificate-1-2: <base64 encoding of CA 2's certificate>
MIDlet-Certificate-1-3: <base64 encoding of CA 1's certificate>
4. Authenticating a Signed MIDlet Suite
Before a MIDlet suite is installed, the Application Management Software (AMS) checks for the presence of the MIDlet-Jar-RSA-SHA1
attribute in the application descriptor and, if it is present, attempts
to authenticate the JAR file by verifying the signer certificate. If it
is not possible to successfully authenticate a signed MIDlet suite, it
is not installed. If the MIDlet suite descriptor file does not include
the MIDlet-Jar-RSASHA1 attribute, then the MIDlet can only be installed as untrusted.
5. Authorization Model
A signed MIDlet
suite containing MIDlets which access protected APIs must explicitly
request the required permissions. The MIDP specification defines two new
attributes, MIDlet-Permissions and MIDlet-Permissions-Opt,
for this purpose. Critical permissions (those that are required for
MIDP access to protected APIs that are essential to the operation of
MIDlets) must be listed under the MIDlet-Permissions
attribute. Non-critical permissions (those required to access protected
APIs without which the MIDlets can run in a restricted mode) should be
listed under the MIDlet-Permissions-Opt attribute.
The MIDlet-Permissions and MIDlet-Permissions-Opt
attributes may appear in the JAD file or the manifest of a signed
MIDlet suite, or in both, in which case their respective values in each
must be identical, but only the values in the manifest are 'protected'
by the signature of the JAR file.
It is important to note that a MIDlet suite that has been installed as
trusted is not granted any permission it has not explicitly requested in
either the MIDlet-Permissions or MIDlet-Permissions-Opt attributes, irrespective of whether it would be granted were it to be requested.
The naming scheme for
permissions is similar to that for Java package names. The exact name of
a permission to access an API or function is defined in the
specification for that API. For instance, an entry requesting permission
to open HTTP and secure HTTP connections would be as follows:
MIDlet-Permissions: javax.microedition.io.Connector.http,
javax.microedition.io.Connector.https
The successful
authorization of a trusted MIDlet suite requires that the requested
critical permissions are recognized by the device (for instance, in the
case of optional APIs) and are granted, or potentially granted, in the
protection domain to which the MIDlet suite would be bound, were it to
be installed. If either of these requirements cannot be satisfied, the
MIDlet suite is not installed.
6. Protection Domains
A protection domain is a
set of permissions determining access to protected APIs or functions. A
permission is either Allowed, in which case MIDlets in MIDlet suites
bound to this protection domain have automatic access to this API, or
User, in which case permission to access the protected API or function
is requested from the user, who can then grant or deny access. In the
case of User permissions, there are three interaction modes:
Blanket – as long as the MIDlet suite is installed, it has this permission unless the user explicitly revokes it.
Session – user authorization is requested the first time the API is invoked and it is in force while the MIDlet is running.
Oneshot – user authorization is requested each time the API is invoked.
The protection domains for a given device are defined in a security policy file. A sample security policy file is shown below:
alias: net_access
javax.microedition.io.Connector.http,
javax.microedition.io.Connector.https,
javax.microedition.io.Connector.datagram,
javax.microedition.io.Connector.datagramreceiver,
javax.microedition.io.Connector.socket,
javax.microedition.io.Connector.serversocket,
javax.microedition.io.Connector.ssl
domain: Untrusted
session (oneshot): net_access
oneshot (oneshot): javax.microedition.io.Connector.sms.send
oneshot (oneshot): javax.microedition.io.Connector.sms.receive
session (oneshot): javax.microedition.io.PushRegistry
domain: Symbian
allow: net_access
allow: javax.microedition.io.Connector.sms.send
allow: javax.microedition.io.Connector.sms.receive
allow: javax.microedition.io.PushRegistry
User permissions may
offer several interaction modes, the user being able to select the level
of access. For instance, the following line indicates that the API or
functions defined under the net_access alias have User permission with either session or oneshot interaction modes, the latter being the default:
session (oneshot): net_access
