The word security has many meanings; the need to hide personal information, user authentication and data encryption are all subjects related to the security topic. We can think, for instance, about what would happen if we download a malign midlet that, at a certain time, starts sending SMS messages to a specific phone number giving away personal information about our agenda or other data stored in our device. In that case the damage affects both privacy and money. In this module we’ll talk about what the MIDP 2.0 specification tells us about security, and we’ll learn how to sign a MIDlet Suite to grant the execution of operations that usually the midlet may only run after a user confirmation. Then we’ll create a simple application and we’ll observe how it runs: our goal is to compare the behavior of a signed and of an unsigned application.
The MIDlet sandbox
The security model depicted by the MIDP 2.0 specification is very similar to the model Java used some J2SE versions ago. Every application – or applet – runs into an environment where some operations aren’t allowed. An applet running into a browser JVM can execute only those operations the JVM allows. The same applies also for a MIDlet application, which can execute only those operations that the environment – the KVM implementation, in this case – allows. This environment is often called sandbox because it’s like a enclosed box in which to play without any risk. From the management point of view, a sandbox consists of these important concepts:
- protection domain
- policy domain
From the point of view of the developer, a permission is an operation or method that the application can execute inside its runtime environment. A permission can be generic or specific and it’s represented by a simple string, resembling the complete path of the operation. For instance, with the permission:
we refer to the set of operations related to push events (sms, http connection and similar). Push Registry is a very smart feature introduced with MIDP 2.0 that we’ll cover in a future module. With the permission:
we describe the permission to create an OBEX connection as a server using the TCP protocol. So, with a permission we can describe an operation, or a set of operations, that we can’t execute without the proper rights.
The second feature is described by the concept of protection domain, which is simply a set of permissions. As we’ll see later, a specific midlet suite cannot be linked to a single permission but, when signed, has to be linked to a protection domain. So, we can associate our midlet suite, through the sign process, with a set of permissions which is called protection domain. When a midlet suite is signed and linked to a specific protection domain, it can do everything the protection domain allows to do.
With the term policy domain we call a set of protection domains and aliases. As we stated before, a protection domain is a set of permissions; some of those permissions may be linked to messaging, others to http connections and so on. Permissions regarding the same area may be grouped together using aliases. So we can give a name – the alias – to a set of permissions belonging a protection domain. In this way we can manage permissions in a simple way but it’s very important to remark that an alias is not a protection domain, but can only be used to describe a part of it.
The last concept is the keystore which is a repository of certificates. As we’ll see later, when we install a signed midlet into a device, it checks for a certificate that can be used to recognize the midlet suite as signed. If no certificate is found, the midlet isn’t secure and the device can advise the user to not install it. On the contrary, if one suitable certificate is found, the device keystore can be used for verifying that the midlet suite is signed, and thus we have what we call a trusted midlet suite.
Trusted and Untrusted Midlet Suites
In MIDP 1.0 there were only untrusted midlet suites. This meant that we just had one protection domain, and that the user was prompted whether to let the application execute some operations (usually I/O operations) or not. The MIDP 2.0 specification, instead, includes two different types of MIDlet Suites:
The trusted ones are linked to a certificate and so they have all the permissions included in the associated protection domain. The untrusted ones are linked to a domain which is often called untrusted domain which has no specific permissions.
How can a device know if a midlet suite is trusted or untrusted? Well, if the midlet suite is signed with a specific certificate, the device will search, into its keystore, for a suitable certificate. The subsystem in charge of associating a specific certificate to a particular protection domain is provided by the device vendor, and so it’s a vendor-specific process. On general terms, we can say that every protection domain is linked to a root certificate the device itself uses to check signed applications. When an application developer signs a midlet suite, he or she can use different certificates released by different certificate authorities. The protection domain linked to the midlet suite will be the one the first matching root certificate recognizes. This means that a midlet suite can be linked to only one protection domain.
How to set the permissions for a midlet suite
From the user interaction point of view, MIDP 2.0 specification describes two different kinds of permissions:
- allowed permission
- user permission
Allowed permissions are those a trusted midlet suite can execute without an explicit user interaction. This kind of permissions are assigned to a signed midlet suite by its protection domain. User permissions requires an interaction with the user: i.e. the user has to explicitly give his or hers permission.
So, if we want a midlet suite to execute a protected API without any user interaction, we have to sign our application using a certificate that the device links to a protection domain in which the API is marked as allowed.
On the other hand, if the midlet suite is linked to a protection domain in which the protected API permission is marked as “user permission”, the application will ask the user if he or she wants to execute it or not. There are three kinds of interaction, distinguished by the rate at which the question is asked. This types of user permission are:
A blanket permission is valid for every instance of the protected API, until the user decides to change this behavior using the device’s management tool.
In the session permission case, the devices prompts the user only the first time the protected API is accessed, and the permission is valid until the midlet is turned off . The user is prompted just one time per midlet execution.
The last kind of user permission is called oneshot, for which the device always prompts the user, even during the same midlet execution.
The policy domain defines how to arrange the permissions: which permissions are “allowed”, which ones are “user”, and – for user permissions – which ones are blanket, session and oneshot.
Sometimes, as we said before, the device allows the user – by means of a management tool – to change the user interaction for some of the permissions. In any case the user has the right to deny the execution of some operations.
How can a midlet tell the device which permissions it needs? Well, we can do this using two specific JAD properties, which are:
The first property contains the list of permissions the midlet suite requires for its proper execution. It’s important to notice that this list of permissions is not linked to the protection domain the device will associate to the application. The developer will manage only the SecurityException the runtime environment will throw if the permission is not allowed. So, the permissions listed in this property are a set of assigned and user permission.
The second property can be employed if the midlet suite uses some permissions but they aren’t mandatory for its execution. It’s the case, for instance, of a game application which can connect to a server to send the top scores. In this case, the connection functionality may not be mandatory: some user may just want to play.
A brief summary
Before creating a simple example of a trusted midlet suite using WTK, we present here a brief summary of permission management.
1) When we develop a midlet belonging to a midlet suite, we have to declare a set of permissions into the JAD file. If a permission is fundamental for the midlet execution, we set it in the MIDlet-permissions property. If the permission is optional we can set it in the MIDlet-Permissions-Opt property. This information is device independent. Each permission may be “allowed” or “user”, depending to the protection domain linked to the root certificate we used to sign the midlet. The type of user permission depends on the device configuration.
2) If some mandatory permissions are unknown to the device, the installation will fail. If these permissions are optional, they will simply be ignored.
3) If some mandatory permissions are not recognized as “allowed” or “user” permissions, the midlet suite will not be installed. If they are optional they will be ignored.
4) All permissions recognized as user permissions will be managed in a device specific way, as we said before.
5) So, permissions granted to the midlet suite are the ones the midlet suite asked for, and which were then granted by the assigned protection domain.
The desired condition is that the midlet is granted all the permissions it needs to run properly; that’s only possible if every permission belonging to the protection domain is known to the device. If some of the requested permissions aren’t contained in the MIDlet-permissions property list, but are used nevertheless, we’ll have a SecurityException the application must manage.
An example of a trusted midlet suite
After the theoretical part of the security management, we’ll see now a simple example on the use of permissions with midlets. What we want to create is a midlet that sends a sms to a specific phone number using the messaging API we’ll see in a future module. The first step is to develop our MIDlet, called SMSSenderMIDlet, in the package it.actionscript.mobile.m06. Without going into detail about the messaging API, what we should notice is the use of an API which requires a permission to execute, and that we inserted into the run() method of the class SMSSender. The first thing we do is running the application as is, without setting up the permissions in the JAD file. If we start the application, insert a phone number and text and then press the Send button, we see what is displayed in Fig6_1.
The device asks the user if he or she wants to send the sms message or not. If the user answers “No”, we have a SecurityException; otherwise the message is sent. We can notice that if we deny the permission and then we retry to send the SMS, we have a SecurityException again. This means that the midlet suite is running into a protection domain that declares the permission linked to the sms-send operation as a user permission of type session. The same happens if we allow the operation by pressing Yes: the user won’t be prompted again for all the time the midlet is running. To see which was the domain assigned to the midlet suite we can execute the WTK preferences tool (Fig6_2).
It’s a tool that allows us to set up the parameters of the emulator we’re using. This can be very useful to test the features of a specific device. If we select the security option, we notice that we can choose the security domain into whom execute our application. The WTK allows us also to choose the security policy. We’ll use JWTI (Java for Wireless and Telephony Industry) for that. What is important for us is the security domain; the domain into which we first executed our midlet was the untrusted one. The untrusted domain tells the device to prompt the user for a sms sending operation. The other possible domains are trusted, minimum and maximum. Now, we select the trusted domain and we run our midlet suite again. What we see is that the device doesn’t prompt the user any more. That means that now the midlet suite is executed as a trusted midlet suite and therefore into a domain that allows the sending of an sms message without asking the permission to the user. For sake of completeness, we can check that the sms arrives using one of the WTK utilities: the WMA Console (Fig6_3).
When we start a WMA Console, the WTK gives it a phone number we can use for our sms-sending tests. We can use this number into our midlet, to check if it works (Fig6_4).
Ok, in the WTK we can choose the protection domain, but in the real world things are different. Before, we learned that to assign a specific protection domain to a midlet suite we have to sign it. If we sign the midlet suite, it will be linked to the domain associated to the certificate we used. The first thing we have to do is to declare the permissions we need into the JAD file using our WTK tool. In the case of sms the JAD becomes:
MIDlet-1: SMSSenderMIDlet, , it.actionscript.mobile.m06.SMSSenderMIDlet
We should remark that now there’s a value for the MIDlet-Permissions property which is the name of the permission for the sending of a sms message. Then, we have to sign the midlet. To do that we can use the “Sign MIDlet” WTK tool. To describe the complete process we start from the creation of a certificate using the J2SE tool without going into details too much. We can use the keytool with this command:
keytool -genkey -alias action -keyalg RSA -validity 365
After executing this command the system will prompt for some information about the organization creating the certificate. The result of this operation is the creation of a certificate in the local keystore of the J2SE. To install it into our phone or, as in our case, into the Sign tool we have to export it from the keystore. To do that we can use the keytool again with this command
keytool -export -alias action -file actionCert.crt
The result is a file called actionCert.crt containing our certificate information. We can import the file into our tool using the Keystore/Import Certificate option (Fig6_5).
Then, we insert the alias and we select the crt file. The result is that the certificate is inserted into the tool as one of the available certificates (Fig6_6). Here we can also see information about the certificate such as the expire date and the certificate fingerprint.
To sign the midlet suite we need a key pair that we can generate using the Keystore/New Key Pair option of our tool (Fig6_7).
Here we can insert information about the company and the alias name. When we press ok we have the important step. Here the tool shows us the list of available protection domains we can associate to the key we’re generating. It’s a fundamental step, since the protection domain we choose here will be the one associated to the midlet when it’ll be executed into the emulator. We choose the trusted one (Fig6_8).
All we have to do now is to sign the midlet suite with the Action/Sign Midlet Suite option of the tool. Here we have to select the jad file we want to sign and then confirm. The midlet is now signed and associated to the trusted domain.
The JAD file becomes:
MIDlet-1: SMSSenderMIDlet, , it.actionscript.mobile.m06.SMSSenderMIDlet
where we can see the certificate information. The good news is that if we try to execute now our midlet into the emulator – the midlet suite being associated to the trusted domain – the sms operation can be done without user confirmation.
What we tried using the WTK is quite similar to the real world scenario. The most important thing is that we must obtain a certificate from a certificate authority known by the device vendor. A word about protection domains: we cannot create a new protection domain, but we just have to use the ones the vendor creates for the specific device.
In this module we covered some important concepts about the MIDP 2.0 environment security, and we described how to sign a midlet using the WTK tools.
 MIDP 2.0 API http://java.sun.com/javame/reference/apis/jsr118/
 API MIDP 2.0 documentation
Related Download: module_06.zip